¿Por qué el entero sin signo no está disponible en PostgreSQL?

Me encontré con esta publicación ( ¿Cuál es la diferencia entre tinyint, smallint, mediumint, bigint e int en MySQL? ) Y me di cuenta de que PostgreSQL no admite enteros sin signo.

¿Alguien puede ayudar a explicar por qué es así?

La mayoría de las veces, utilizo un entero sin firmar como clave primaria autoincrementada en MySQL. En tal diseño, ¿cómo puedo superar esto cuando transfiero mi base de datos de MySQL a PostgreSQL?

Gracias.

Ya se ha respondido por qué postgresql carece de tipos sin firmar. Sin embargo, sugeriría usar dominios para tipos sin firmar.

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

El dominio es como un tipo pero con una restricción adicional.

Para un ejemplo concreto, podría usar

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

Esto es lo que psql da cuando trato de abusar del tipo.

DS1 = # seleccionar (346346 :: uint2);

ERROR: el valor del dominio uint2 viola la restricción de verificación "uint2_check"

No está en el estándar SQL, por lo que la necesidad general de implementarlo es menor.

Tener demasiados tipos de enteros diferentes hace que el sistema de resolución de tipos sea más frágil, por lo que existe cierta resistencia a agregar más tipos a la mezcla.

Dicho esto, no hay ninguna razón por la que no se pueda hacer. Es mucho trabajo.

Puede utilizar una restricción CHECK, por ejemplo:

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

Además, PostgreSQL tiene smallserial, serialy bigserialtipos de incremento automático.

La charla sobre DOMINIOS es interesante pero no relevante para el único origen posible de esa pregunta. El deseo de ints sin firmar es duplicar el rango de ints con el mismo número de bits, es un argumento de eficiencia, no el deseo de excluir números negativos, todos saben cómo agregar una restricción de verificación.

Cuando alguien le preguntó al respecto , Tome Lane declaró:

Básicamente, hay cero posibilidades de que esto suceda a menos que pueda encontrar una manera de encajarlos en la jerarquía de promoción numérica que no rompa muchas aplicaciones existentes. Hemos examinado esto más de una vez, si la memoria no me falla, y no pudimos encontrar un diseño viable que no pareciera violar la POLA.

¿Qué es el "POLA"? Google me dio 10 resultados que no tienen sentido . No estoy seguro de si es un pensamiento políticamente incorrecto y, por lo tanto, está censurado. ¿Por qué este término de búsqueda no da ningún resultado? Lo que sea.

Puede implementar entradas sin firmar como tipos de extensión sin demasiados problemas. Si lo hace con funciones C, no habrá ninguna penalización de rendimiento. No necesitará extender el analizador para tratar con literales porque PgSQL tiene una manera tan fácil de interpretar cadenas como literales, simplemente escriba '4294966272' :: uint4 como sus literales. Los yesos tampoco deberían ser un gran problema. Ni siquiera necesita hacer excepciones de rango, simplemente puede tratar la semántica de '4294966273' :: uint4 :: int como -1024. O puede lanzar un error.

Si hubiera querido esto, lo habría hecho. Pero como estoy usando Java en el otro lado de SQL, para mí tiene poco valor ya que Java tampoco tiene esos enteros sin firmar. Entonces no gano nada. Ya estoy molesto si obtengo un BigInteger de una columna bigint, cuando debería caber en long.

Otra cosa, si tuviera la necesidad de almacenar tipos de 32 bits o 64 bits, puedo usar PostgreSQL int4 o int8 respectivamente, solo recordando que el orden natural o la aritmética no funcionarán de manera confiable. Pero el almacenamiento y la recuperación no se ven afectados por eso.

Así es como puedo implementar un int8 simple sin firmar:

Primero usaré

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
)

las 2 funciones mínimas uint8_iny uint8_outprimero debo definir.

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;

Necesito implementar esto en C uint8_funcs.c. Entonces uso el ejemplo complejo de aquí y lo hago simple:

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, bueno, o puede encontrarlo ya hecho .

De acuerdo con la documentación más reciente, se admite el entero sin signo, pero no el entero sin signo en la tabla. Sin embargo, el tipo de serie es similar a unsigned excepto que comienza desde 1 y no desde cero. Pero el límite superior es el mismo que chamuscado. Entonces, el sistema realmente no tiene soporte sin firmar. Como señaló Peter, la puerta está abierta para implementar la versión sin firmar. Es posible que el código tenga que actualizarse mucho, demasiado trabajo de mi experiencia trabajando con la programación 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 tiene un tipo entero sin signo que es desconocido para muchos: OID.

El oidtipo se implementa actualmente como un entero de cuatro bytes sin signo. […]

El oidtipo en sí tiene pocas operaciones más allá de la comparación. Sin embargo, se puede convertir a entero y luego manipular utilizando los operadores de enteros estándar. (Tenga cuidado con la posible confusión entre firmados y no firmados si hace esto).

Sin embargo, no es un tipo numérico , y tratar de hacer cualquier aritmética (o incluso operaciones bit a bit) con él va a fallar. Además, son solo 4 bytes ( INTEGER), no hay un BIGINTtipo sin firmar de 8 bytes ( ) correspondiente .

Por lo tanto, no es realmente una buena idea usar esto usted mismo, y estoy de acuerdo con todas las otras respuestas en que en un diseño de base de datos de Postgresql siempre debe usar una columna INTEGERo BIGINTpara su clave principal de serie , que comience en negativo ( MINVALUE) o lo permita to wrap around ( CYCLE) si desea agotar el dominio completo.

Sin embargo, es bastante útil para la conversión de entrada / salida, como su migración desde otro DBMS. Insertar el valor 2147483648en una columna de números enteros dará lugar a un " ERROR: número entero fuera de rango ", mientras que el uso de la expresión 2147483648::OIDfunciona bien.
Del mismo modo, al seleccionar una columna entera como texto con mycolumn::TEXT, obtendrá valores negativos en algún momento, pero con mycolumn::OID::TEXTsiempre obtendrá un número natural.

Vea un ejemplo en dbfiddle.uk .