database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-27 12:41:57 +03:00
Code Activity

Relax transactional restrictions on ALTER TYPE ... ADD VALUE.

Browse Source 
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.

Andrew Dunstan and Tom Lane

Discussion: <4075.1459088427@sss.pgh.pa.us>
This commit is contained in:
Tom Lane
2016-09-05 12:59:55 -04:00
parent 016abf1fb8
commit 15bc038f9b
8 changed files with 191 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/ref/alter_type.sgml
View File

@ -266,8 +266,10 @@ ALTER TYPE <replaceable class="PARAMETER">name</replaceable> ADD VALUE [ IF NOT
<title>Notes</title>
<para>
<command>ALTER TYPE ... ADD VALUE</> (the form that adds a new value to an
enum type) cannot be executed inside a transaction block.
If <command>ALTER TYPE ... ADD VALUE</> (the form that adds a new value to
an enum type) is executed inside a transaction block, the new value cannot
be used until after the transaction has been committed, except in the case
that the enum type itself was created earlier in the same transaction.
</para>
<para>