ошибка: ALTER TYPE ... ADD не может работать внутри блока транзакции

Question

Я пытаюсь добавить новое значение типа к моим существующим типам в PostgreSQL. Но я получаю следующую ошибку

ошибка: ALTER TYPE ... ADD не может работать внутри блока транзакции

Запрос, который я использовал для добавления нового значения в тип:

ALTER TYPE public.request_type ADD VALUE "Check";

Я на самом деле выполняю запрос выше в файле миграции, который создан с помощью node-pg-migrate

Здесь public - моя схема.

Есть идеи, почему это не удается?

Edit:

Приведенный ниже запрос выполняется нормально при выполнении его в pgadmin

ALTER TYPE public.request_type ADD VALUE "Check";

Но когда я запускаю указанную выше команду через миграцию node-pg-migrate, она завершается неудачно и выдает ошибку выше

Answer 1

Обходной путь для более ранних версий PostgreSQL , показанный здесь :

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

• Замените 'NEW_ENUM_VALUE' нужным значением.
• Замените 'type_egais_units' на oid перечисления, которое вы хотите изменить. (Используйте SELECT * FROM pg_enum, чтобы найти перечисление, которое вы хотите обновить, в моем случае это было 5-значное число, например '19969')

Утверждение:

INSERT INTO pg_enum (
    enumtypid, 
    enumlabel, 
    enumsortorder
)
SELECT 
    'type_egais_units'::regtype::oid, 
    'NEW_ENUM_VALUE', 
    (SELECT MAX(enumsortorder) + 1 FROM pg_enum WHERE enumtypid = 'type_egais_units'::regtype)

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

Кто-нибудь знает, как избежать использования транзакций при выполнении запросов из pgAdmin версии 3.5? (т.е. при выполнении с F5 ?)

Answer 2

Как уже упоминалось выше, вы не можете редактировать enum в блоке транзакции. Но вы можете создать новый. Вот шаги:

1. Изменить тип с request_type на varchar для всех столбцов / таблиц, которые используют этот тип:

ALTER TABLE table_name ALTER COLUMN request_type TYPE VARCHAR(255);

2. Удалить и создать заново request_type enum:

DROP TYPE IF EXISTS request_type;
CREATE TYPE request_type AS ENUM ('OLD_VALUE_1', 'OLD_VALUE_2', 'NEW_VALUE_1', 'NEW_VALUE_2'); 

3. Вернуть тип из varchar в request_type для всех столбцов / таблиц (отменить первый шаг):

ALTER TABLE table_name ALTER COLUMN request_type TYPE request_type USING (request_type::request_type);

Answer 3

Причина указана в следующем комментарии в AlterEnum в src/backend/commands/typecmds.c:

/*
 * Ordinarily we disallow adding values within transaction blocks,
 * because we can't cope with enum OID values getting into indexes and
 * then having their defining pg_enum entries go away.  However, it's
 * okay if the enum type was created in the current transaction, since
 * then there can be no such indexes that wouldn't themselves go away
 * on rollback.  (We support this case because pg_dump
 * --binary-upgrade needs it.)

Обратите внимание, что это ограничение было снято в commit 212fab99 ; сообщение о фиксации гласит:

To prevent possibly breaking indexes on enum columns, we must keep
uncommitted enum values from getting stored in tables, unless we
can be sure that any such column is new in the current transaction.

Formerly, we enforced this by disallowing ALTER TYPE ... ADD VALUE
from being executed at all in a transaction block, unless the target
enum type had been created in the current transaction.  This patch
removes that restriction, and instead insists that an uncommitted enum
value can't be referenced unless it belongs to an enum type created
in the same transaction as the value.  Per discussion, this should be
a bit less onerous.  It does require each function that could possibly
return a new enum value to SQL operations to check this restriction,
but there aren't so many of those that this seems unmaintainable.

Так что вы можете обновить до PostgreSQL v12 в ближайшее время: ^)