Почему целое число без знака недоступно в 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, поэтому общая потребность в его реализации ниже.

Наличие слишком большого количества различных целочисленных типов делает систему разрешения типов более хрупкой, поэтому есть некоторое сопротивление добавлению большего количества типов в смесь.

Тем не менее, нет никаких причин, по которым этого нельзя было бы сделать. Это просто большая работа.

Вы можете использовать ограничение CHECK, например:

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

Кроме того , PostgreSQL имеет smallserial, serialи bigserialтипов для автоматического увеличения.

Разговор о DOMAINS интересен, но не имеет отношения к единственно возможному источнику этого вопроса. Желание беззнаковых целых чисел состоит в том, чтобы удвоить диапазон целых чисел с тем же количеством битов, это аргумент эффективности, а не желание исключить отрицательные числа, каждый знает, как добавить ограничение проверки.

Когда кто-то спросил об этом , Том Лейн сказал:

По сути, это нулевой шанс, что это произойдет, если вы не найдете способ вписать их в числовую иерархию продвижения, которая не нарушила бы многие существующие приложения. Мы смотрели на это не раз, если мне не изменяет память, и не смогли придумать работоспособный дизайн, который, похоже, не нарушал бы POLA.

Что такое «ПОЛА»? Google дал мне 10 результатов, которые не имеют смысла . Не уверен, что это политически некорректная мысль и поэтому подвергается цензуре. Почему этот поисковый запрос не даст никакого результата? Без разницы.

Вы можете без особых проблем реализовать беззнаковые целые числа как типы расширения. Если вы сделаете это с помощью C-функций, то вообще не будет никаких штрафов за производительность. Вам не нужно расширять синтаксический анализатор для работы с литералами, потому что PgSQL имеет такой простой способ интерпретировать строки как литералы, просто напишите '4294966272' :: uint4 в качестве литералов. Броски тоже не должны иметь большого значения. Вам даже не нужно делать исключения диапазона, вы можете просто обработать семантику '4294966273' :: uint4 :: int как -1024. Или можете выдать ошибку.

Если бы я этого хотел, я бы это сделал. Но поскольку я использую Java на другой стороне SQL, для меня это не имеет большого значения, поскольку в Java нет этих целых чисел без знака. Так что я ничего не получаю. Меня уже раздражает, если я получаю BigInteger из столбца bigint, когда он должен уместиться в long.

Другое дело, если бы мне действительно нужно было хранить 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), нет соответствующего 8-байтового ( BIGINT) беззнакового типа.

Так что использовать это самостоятельно не очень хорошая идея, и я согласен со всеми другими ответами, что в дизайне базы данных Postgresql вы всегда должны использовать столбец INTEGERили BIGINTдля своего серийного первичного ключа - чтобы он начинался с отрицательного ( MINVALUE) или разрешал его to wrap around ( CYCLE), если вы хотите исчерпать весь домен.

Однако он очень полезен для преобразования ввода / вывода, например, при переходе с другой СУБД. Вставка значения 2147483648в целочисленный столбец приведет к ошибке « ОШИБКА: целое число вне допустимого диапазона », в то время как использование выражения 2147483648::OIDработает нормально.
Точно так же при выборе целочисленного столбца в качестве текста с помощью mycolumn::TEXTвы в какой-то момент получите отрицательные значения, но с mycolumn::OID::TEXTвы всегда получите натуральное число.

См. Пример на dbfiddle.uk .