Добавление первичного ключа изменяет тип столбца - PullRequest
1 голос
/ 29 февраля 2012

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

Моя проблема: В Postgres 8.4.7 одна таблица, в частности, изменяет тип данных с bigint на integer, когда я добавляю первичный ключ в таблицу.

У меня есть следующее определение таблицы:

psql=# \d events
                                         Table "public.events"
        Column         |           Type           |                      Modifiers                      
-----------------------+--------------------------+-----------------------------------------------------
 id                    | bigint                   | not null default nextval('events_id_seq'::regclass)
 [more columns omitted]

Indexes:
    "events_id_unique_pk" UNIQUE, btree (id)
Foreign-key constraints:
    "events_clearing_event_ref_fk" FOREIGN KEY (clearing_event_id) REFERENCES events(id)
    "events_event_configs_id_fk" FOREIGN KEY (event_config_id) REFERENCES event_configs(id)
    "events_pdu_circuitbreaker_id_fk" FOREIGN KEY (pdu_circuitbreaker_id) REFERENCES pdu_circuitbreaker(id)
    "events_pdu_id_fk" FOREIGN KEY (pdu_id) REFERENCES pdus(id) ON DELETE CASCADE
    "events_pdu_outlet_id_fk" FOREIGN KEY (pdu_outlet_id) REFERENCES pdu_outlet(id)
    "events_sensor_id_fk" FOREIGN KEY (sensor_id) REFERENCES sensors(id)
    "events_user_id_fk" FOREIGN KEY (clearing_user_id) REFERENCES users(id)
Referenced by:
    TABLE "events" CONSTRAINT "events_clearing_event_ref_fk" FOREIGN KEY (clearing_event_id) REFERENCES events(id)
    TABLE "event_params" CONSTRAINT "events_params_event_id_fk" FOREIGN KEY (event_id) REFERENCES events(id) ON DELETE CASCADE
Triggers:
    event_validate BEFORE INSERT OR UPDATE ON events FOR EACH ROW EXECUTE PROCEDURE event_validate()

Вот что происходит:

psql=# ALTER TABLE events ADD PRIMARY KEY (id);
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "events_pkey" for table "events"
ALTER TABLE
psql=# \d events
                                         Table "public.events"
        Column         |           Type           |                      Modifiers                      
-----------------------+--------------------------+-----------------------------------------------------
 id                    | integer                  | not null default nextval('events_id_seq'::regclass)
 [more columns omitted]

Indexes:
    "events_pkey" PRIMARY KEY, btree (id)
    "events_id_unique_pk" UNIQUE, btree (id)
Foreign-key constraints:
    "events_clearing_event_ref_fk" FOREIGN KEY (clearing_event_id) REFERENCES events(id)
    "events_event_configs_id_fk" FOREIGN KEY (event_config_id) REFERENCES event_configs(id)
    "events_pdu_circuitbreaker_id_fk" FOREIGN KEY (pdu_circuitbreaker_id) REFERENCES pdu_circuitbreaker(id)
    "events_pdu_id_fk" FOREIGN KEY (pdu_id) REFERENCES pdus(id) ON DELETE CASCADE
    "events_pdu_outlet_id_fk" FOREIGN KEY (pdu_outlet_id) REFERENCES pdu_outlet(id)
    "events_sensor_id_fk" FOREIGN KEY (sensor_id) REFERENCES sensors(id)
    "events_user_id_fk" FOREIGN KEY (clearing_user_id) REFERENCES users(id)
Referenced by:
    TABLE "events" CONSTRAINT "events_clearing_event_ref_fk" FOREIGN KEY (clearing_event_id) REFERENCES events(id)
    TABLE "event_params" CONSTRAINT "events_params_event_id_fk" FOREIGN KEY (event_id) REFERENCES events(id) ON DELETE CASCADE
Triggers:
    event_validate BEFORE INSERT OR UPDATE ON events FOR EACH ROW EXECUTE PROCEDURE event_validate()

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

Это написано в Liquibase, но это также происходит непосредственно в консоли Postgres.


Обновление

Два других пункта:

  • Я могу создать простую таблицу с идентификатором bigint и уникальным индексом для id, добавить первичный ключ, и тип столбца останется прежним.
  • На момент исполнения все таблицы пусты.

Может ли это иметь какое-то отношение к ограничениям?

Ответы [ 2 ]

1 голос
/ 20 июня 2012

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

1 голос
/ 16 апреля 2012

Это довольно интересно. Я не могу воспроизвести его с версией 9.1.0 (да, я тоже должен обновить!). Но тогда я точно не знаю, как были созданы исходная таблица и последовательность.

Эта страница, похоже, ссылается на аналогичное автоматическое изменение типов между SERIAL и INTEGER: http://grover.open2space.com/content/migrate-data-postgresql-and-maintain-existing-primary-key

Может ли это быть что-то вроде создания таблицы с использованием SERIAL вместо BIGSERIAL, а затем принудительное приведение типа к BIGINT? Что-то между последовательностью и манипуляциями с первичным ключом могло сбрасывать ее.

...