เหตุใดจำนวนเต็มที่ไม่ได้ลงชื่อจึงไม่มีใน PostgreSQL

ฉันเจอโพสต์นี้ ( ความแตกต่างระหว่าง tinyint, smallint, mediumint, bigint และ int ใน MySQL คืออะไร ) และตระหนักว่า PostgreSQL ไม่รองรับจำนวนเต็มที่ไม่ได้ลงชื่อ

ใครช่วยอธิบายได้ไหมว่าทำไมถึงเป็นเช่นนั้น?

ส่วนใหญ่ฉันใช้จำนวนเต็มที่ไม่ได้ลงชื่อเป็นคีย์หลักที่เพิ่มขึ้นโดยอัตโนมัติใน MySQL ในการออกแบบเช่นนี้ฉันจะเอาชนะสิ่งนี้ได้อย่างไรเมื่อฉันพอร์ตฐานข้อมูลจาก MySQL ไปยัง PostgreSQL

ขอบคุณ.

มีคำตอบแล้วว่าทำไม postgresql ถึงไม่มีประเภทที่ไม่ได้ลงนาม อย่างไรก็ตามฉันขอแนะนำให้ใช้โดเมนสำหรับประเภทที่ไม่ได้ลงชื่อ

http://www.postgresql.org/docs/9.4/static/sql-createdomain.html

 CREATE DOMAIN name [ AS ] data_type
    [ COLLATE collation ]
    [ DEFAULT expression ]
    [ constraint [ ... ] ]
 where constraint is:
 [ CONSTRAINT constraint_name ]
 { NOT NULL | NULL | CHECK (expression) }

โดเมนก็เหมือนกับประเภทหนึ่ง แต่มีข้อ จำกัด เพิ่มเติม

สำหรับตัวอย่างที่เป็นรูปธรรมคุณสามารถใช้ได้

CREATE DOMAIN uint2 AS int4
   CHECK(VALUE >= 0 AND VALUE < 65536);

นี่คือสิ่งที่ psql ให้เมื่อฉันพยายามละเมิดประเภท

DS1 = # เลือก (346346 :: uint2);

ข้อผิดพลาด: ค่าสำหรับโดเมน uint2 ละเมิดข้อ จำกัด การตรวจสอบ "uint2_check"

ไม่อยู่ในมาตรฐาน SQL ดังนั้นความต้องการทั่วไปในการใช้งานจึงต่ำกว่า

การมีประเภทจำนวนเต็มที่แตกต่างกันมากเกินไปทำให้ระบบการแก้ปัญหาประเภทมีความเปราะบางมากขึ้นดังนั้นจึงมีความต้านทานต่อการเพิ่มประเภทอื่น ๆ ในการผสม

ที่กล่าวมาไม่มีเหตุผลว่าทำไมถึงทำไม่ได้ ก็แค่งานเยอะ

คุณสามารถใช้ข้อ จำกัด การตรวจสอบเช่น:

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric CHECK (price > 0)
);

นอกจากนี้ PostgreSQL มีsmallserial, serialและbigserialประเภทสำหรับรถยนต์ที่เพิ่มขึ้น

การพูดคุยเกี่ยวกับ DOMAINS นั้นน่าสนใจ แต่ไม่เกี่ยวข้องกับที่มาที่เป็นไปได้เพียงประการเดียวของคำถามนั้น ความปรารถนาสำหรับ ints ที่ไม่ได้ลงนามคือการเพิ่มช่วงของ ints เป็นสองเท่าด้วยจำนวนบิตเท่ากันมันเป็นอาร์กิวเมนต์ที่มีประสิทธิภาพไม่ใช่ความปรารถนาที่จะยกเว้นตัวเลขเชิงลบทุกคนรู้วิธีเพิ่มข้อ จำกัด ในการตรวจสอบ

เมื่อมีคนถามเกี่ยวกับเรื่องนี้ Tome Lane กล่าวว่า:

โดยทั่วไปแล้วจะไม่มีโอกาสเกิดขึ้นเว้นแต่คุณจะสามารถหาวิธีปรับให้เข้ากับลำดับชั้นการโปรโมตแบบตัวเลขที่ไม่ทำลายแอปพลิเคชันที่มีอยู่จำนวนมากได้ เราได้ตรวจสอบสิ่งนี้มากกว่าหนึ่งครั้งหากหน่วยความจำทำงานและล้มเหลวในการออกแบบที่ใช้งานได้ซึ่งดูเหมือนจะไม่ละเมิด POLA

"POLA" คืออะไร? Google ให้ผม 10 ผลลัพธ์ที่มีความหมาย ไม่แน่ใจว่าเป็นความคิดที่ไม่ถูกต้องทางการเมืองจึงถูกเซ็นเซอร์ เหตุใดข้อความค้นหานี้จึงไม่ให้ผลลัพธ์ใด ๆ ก็ตาม.

คุณสามารถใช้ ints ที่ไม่ได้ลงชื่อเป็นประเภทส่วนขยายได้โดยไม่มีปัญหามากเกินไป หากคุณใช้ฟังก์ชัน C จะไม่มีบทลงโทษเกี่ยวกับประสิทธิภาพเลย คุณไม่จำเป็นต้องขยายตัวแยกวิเคราะห์เพื่อจัดการกับตัวอักษรเนื่องจาก PgSQL มีวิธีง่ายๆในการตีความสตริงเป็นตัวอักษรเพียงเขียน '4294966272' :: uint4 เป็นตัวอักษรของคุณ การร่ายไม่ควรเป็นเรื่องใหญ่เช่นกัน คุณไม่จำเป็นต้องทำข้อยกเว้นช่วงคุณสามารถจัดการความหมายของ '4294966273' :: uint4 :: int เป็น -1024 ได้ หรือคุณสามารถโยนข้อผิดพลาด

ถ้าฉันต้องการสิ่งนี้ฉันจะทำมัน แต่เนื่องจากฉันใช้ Java ในอีกด้านหนึ่งของ SQL สำหรับฉันแล้วมันมีค่าเพียงเล็กน้อยเนื่องจาก Java ไม่มีจำนวนเต็มที่ไม่ได้ลงชื่อ ดังนั้นฉันจึงไม่ได้รับอะไรเลย ฉันรู้สึกรำคาญอยู่แล้วถ้าฉันได้รับ BigInteger จากคอลัมน์ bigint เมื่อมันควรจะยาว

อีกประการหนึ่งถ้าฉันมีความจำเป็นในการจัดเก็บประเภท 32 บิตหรือ 64 บิตฉันสามารถใช้ PostgreSQL int4 หรือ int8 ตามลำดับเพียงแค่จำไว้ว่าลำดับธรรมชาติหรือเลขคณิตจะไม่ทำงานอย่างน่าเชื่อถือ แต่การจัดเก็บและการเรียกคืนจะไม่ได้รับผลกระทบจากสิ่งนั้น

นี่คือวิธีที่ฉันสามารถใช้ int8 แบบธรรมดาที่ไม่ได้ลงชื่อ:

ก่อนอื่นฉันจะใช้

CREATE TYPE name (
    INPUT = uint8_in,
    OUTPUT = uint8_out
    [, RECEIVE = uint8_receive ]
    [, SEND = uint8_send ]
    [, ANALYZE = uint8_analyze ]
    , INTERNALLENGTH = 8
    , PASSEDBYVALUE ]
    , ALIGNMENT = 8
    , STORAGE = plain
    , CATEGORY = N
    , PREFERRED = false
    , DEFAULT = null
)

น้อยที่สุด 2 ฟังก์ชั่นuint8_inและuint8_outฉันต้องกำหนดก่อน

CREATE FUNCTION uint8_in(cstring)
    RETURNS uint8
    AS 'uint8_funcs'
    LANGUAGE C IMMUTABLE STRICT;

CREATE FUNCTION uint64_out(complex)
    RETURNS cstring
    AS 'uint8_funcs'
    LANGUAGE C IMMUTABLE STRICT;

จำเป็นต้องใช้สิ่งนี้ใน C uint8_funcs.c ดังนั้นฉันจะใช้ตัวอย่างที่ซับซ้อนจากที่นี่และทำให้มันง่าย:

PG_FUNCTION_INFO_V1(complex_in);

Datum complex_in(PG_FUNCTION_ARGS) {
    char       *str = PG_GETARG_CSTRING(0);
    uint64_t   result;

    if(sscanf(str, "%llx" , &result) != 1)
        ereport(ERROR,
                (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
                 errmsg("invalid input syntax for uint8: \"%s\"", str)));

    return (Datum)SET_8_BYTES(result);
}

อาดีหรือคุณสามารถเพียงแค่พบว่ามันทำมาแล้ว

ตามเอกสารล่าสุดรองรับเลขจำนวนเต็มเดี่ยว แต่ไม่มีจำนวนเต็มที่ไม่ได้ลงชื่อในตาราง อย่างไรก็ตามประเภทซีเรียลนั้นคล้ายกับไม่ได้ลงนามยกเว้นจะเริ่มจาก 1 ไม่ใช่จากศูนย์ แต่ขีด จำกัด บนจะเหมือนกับที่ร้องเพลง ดังนั้นระบบจึงไม่มีการสนับสนุนที่ไม่ได้ลงนามอย่างแท้จริง ตามที่ปีเตอร์ชี้ให้เห็นประตูเปิดให้ใช้งานเวอร์ชันที่ไม่ได้ลงนาม โค้ดอาจต้องได้รับการอัปเดตเป็นจำนวนมากเพียงแค่ทำงานมากเกินไปจากประสบการณ์ของฉันในการทำงานกับการเขียนโปรแกรม C

https://www.postgresql.org/docs/10/datatype-numeric.html

integer     4 bytes     typical choice for integer  -2147483648 to +2147483647
serial  4 bytes     autoincrementing integer    1 to 2147483647

Postgres OIDจะมีชนิดจำนวนเต็มไม่ได้ลงนามที่เป็นถิ่นหลาย

oidชนิดถูกนำมาใช้ในปัจจุบันเป็นจำนวนเต็มสี่ไบต์ […]

oidประเภทตัวเองมีการดำเนินงานไม่กี่นอกเหนือการเปรียบเทียบ อย่างไรก็ตามสามารถแคสต์เป็นจำนวนเต็มอย่างไรก็ตามจากนั้นจัดการโดยใช้ตัวดำเนินการจำนวนเต็มมาตรฐาน (ระวังความสับสนที่อาจเกิดขึ้นระหว่างการลงชื่อและไม่ได้ลงนามหากคุณทำเช่นนี้)

แม้ว่าจะไม่ใช่ประเภทตัวเลขและการพยายามทำเลขคณิตใด ๆ (หรือแม้แต่การดำเนินการแบบบิต) ก็จะล้มเหลว นอกจากนี้ยังเป็นเพียง 4 ไบต์ ( INTEGER) ไม่มีBIGINTประเภทที่ไม่ได้ลงนาม8 ไบต์ ( ) ที่ตรงกัน

ดังนั้นจึงไม่ใช่ความคิดที่ดีที่จะใช้สิ่งนี้ด้วยตัวเองและฉันเห็นด้วยกับคำตอบอื่น ๆ ทั้งหมดที่ในการออกแบบฐานข้อมูล Postgresql คุณควรใช้คอลัมน์INTEGERหรือBIGINTคอลัมน์สำหรับคีย์หลักแบบอนุกรมของคุณเสมอโดยเริ่มต้นด้วยค่าลบ ( MINVALUE) หรืออนุญาต เพื่อตัดรอบ ( CYCLE) หากคุณต้องการใช้โดเมนแบบเต็ม

อย่างไรก็ตามมันมีประโยชน์มากสำหรับการแปลงอินพุต / เอาต์พุตเช่นการย้ายข้อมูลจาก DBMS อื่น การแทรกค่า2147483648ลงในคอลัมน์จำนวนเต็มจะนำไปสู่ ​​" ข้อผิดพลาด: จำนวนเต็มอยู่นอกช่วง " ในขณะที่การใช้นิพจน์2147483648::OIDก็ใช้ได้ดี
ในทำนองเดียวกันเมื่อเลือกคอลัมน์จำนวนเต็มเป็นข้อความmycolumn::TEXTคุณจะได้รับค่าลบ ณ จุดใดจุดหนึ่ง แต่mycolumn::OID::TEXTคุณจะได้จำนวนธรรมชาติเสมอ

ดูตัวอย่างที่ dbfiddle.uk