Perché il numero intero senza segno non è disponibile in PostgreSQL?

Mi sono imbattuto in questo post ( Qual è la differenza tra tinyint, smallint, mediumint, bigint e int in MySQL? ) E mi sono reso conto che PostgreSQL non supporta interi senza segno.

Qualcuno può aiutare a spiegare perché è così?

La maggior parte delle volte, utilizzo un numero intero senza segno come chiave primaria con incremento automatico in MySQL. In tale progettazione, come posso superare questo problema quando porto il mio database da MySQL a PostgreSQL?

Grazie.

È già stato risposto perché a postgresql mancano i tipi non firmati. Tuttavia, suggerirei di utilizzare i domini per i tipi non firmati.

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) }

Il dominio è come un tipo ma con un vincolo aggiuntivo.

Per un esempio concreto potresti usare

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

Ecco cosa dà psql quando provo ad abusare del tipo.

DS1 = # select (346346 :: uint2);

ERRORE: il valore per il dominio uint2 viola il vincolo di controllo "uint2_check"

Non è nello standard SQL, quindi la necessità generale di implementarlo è inferiore.

Avere troppi tipi interi diversi rende il sistema di risoluzione dei tipi più fragile, quindi c'è una certa resistenza all'aggiunta di più tipi nel mix.

Detto questo, non c'è motivo per cui non possa essere fatto. È solo un sacco di lavoro.

Puoi utilizzare un vincolo CHECK, ad esempio:

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

Inoltre, PostgreSQL ha smallserial, seriale bigserialtipi per l'incremento automatico.

Il discorso sui DOMINI è interessante ma non pertinente all'unica possibile origine di quella domanda. Il desiderio di int senza segno è di raddoppiare l'intervallo di int con lo stesso numero di bit, è un argomento di efficienza, non il desiderio di escludere numeri negativi, tutti sanno come aggiungere un vincolo di controllo.

Alla domanda di qualcuno al riguardo , Tome Lane ha dichiarato:

Fondamentalmente, non ci sono possibilità che ciò accada a meno che non si riesca a trovare un modo per inserirli nella gerarchia delle promozioni numeriche che non interrompa molte applicazioni esistenti. Abbiamo esaminato questo aspetto più di una volta, se la memoria serve, e non siamo riusciti a trovare un design funzionante che non sembrava violare il POLA.

Cos'è la "POLA"? Google mi ha dato 10 risultati privi di significato . Non sono sicuro che sia un pensiero politicamente scorretto e quindi censurato. Perché questo termine di ricerca non produce alcun risultato? Qualunque cosa.

Puoi implementare int senza segno come tipi di estensione senza troppi problemi. Se lo fai con le funzioni C, non ci saranno affatto penalità sulle prestazioni. Non sarà necessario estendere il parser per gestire i letterali perché PgSQL ha un modo così semplice per interpretare le stringhe come letterali, basta scrivere "4294966272" :: uint4 come letterali. Anche i cast non dovrebbero essere un grosso problema. Non è nemmeno necessario fare eccezioni di intervallo, puoi semplicemente trattare la semantica di "4294966273" :: uint4 :: int come -1024. Oppure puoi lanciare un errore.

Se avessi voluto questo, l'avrei fatto. Ma dal momento che sto usando Java sull'altro lato di SQL, per me è di scarso valore poiché Java non ha nemmeno quegli interi senza segno. Quindi non guadagno nulla. Sono già infastidito se ottengo un BigInteger da una colonna bigint, quando dovrebbe rientrare in long.

Un'altra cosa, se avessi la necessità di memorizzare i tipi a 32 o 64 bit, posso usare PostgreSQL int4 o int8 rispettivamente, ricordando solo che l'ordine naturale o l'aritmetica non funzioneranno in modo affidabile. Ma la memorizzazione e il recupero non ne sono influenzati.

Ecco come posso implementare un semplice int8 senza segno:

Per prima cosa userò

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
)

le 2 funzioni minime uint8_ine uint8_outdevo prima definire.

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;

è necessario implementarlo in C uint8_funcs.c. Quindi uso l'esempio complesso da qui e lo rendo semplice:

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);
}

ah beh, o puoi semplicemente trovarlo già fatto .

Secondo la documentazione più recente, il numero intero singed è supportato ma nessun numero intero senza segno nella tabella. Tuttavia, il tipo seriale è simile a unsigned tranne che inizia da 1 e non da zero. Ma il limite superiore è lo stesso di bruciato. Quindi il sistema non ha davvero un supporto non firmato. Come sottolineato da Peter, la porta è aperta per implementare la versione non firmata. Il codice potrebbe dover essere aggiornato molto, solo troppo lavoro dalla mia esperienza di lavoro con la programmazione 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 ha un tipo intero senza segno che è all'insaputa di molti: OID.

Il oidtipo è attualmente implementato come intero a quattro byte senza segno. [...]

Il oidtipo stesso ha poche operazioni oltre il confronto. Tuttavia, può essere convertito in numero intero e quindi manipolato utilizzando gli operatori interi standard. (Fai attenzione alla possibile confusione tra segno e non segno se lo fai.)

Tuttavia, non è un tipo numerico e provare a eseguire operazioni aritmetiche (o anche operazioni bit per bit) con esso fallirà. Inoltre, sono solo 4 byte ( INTEGER), non esiste un BIGINTtipo senza segno corrispondente a 8 byte ( ).

Quindi non è proprio una buona idea usarlo da soli, e sono d'accordo con tutte le altre risposte che in un progetto di database Postgresql dovresti sempre usare una colonna INTEGERo BIGINTper la tua chiave primaria seriale - facendola iniziare in negativo ( MINVALUE) o consentendola per avvolgere ( CYCLE) se vuoi esaurire l'intero dominio.

Tuttavia, è abbastanza utile per la conversione di input / output, come la migrazione da un altro DBMS. L'inserimento del valore 2147483648in una colonna di numeri interi porterà a un " ERRORE: numero intero fuori intervallo ", mentre l'uso dell'espressione 2147483648::OIDfunziona perfettamente.
Allo stesso modo, quando selezioni una colonna di numeri interi come testo con mycolumn::TEXT, a un certo punto otterrai valori negativi, ma con mycolumn::OID::TEXTotterrai sempre un numero naturale.

Guarda un esempio su dbfiddle.uk .