Horton

Re: Transactional enum additions - was Re: Alter or rename enum value

Andrew Dunstan <andrew@dunslane.net>

View thread View on postgr.es
From: Andrew Dunstan <andrew@dunslane.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Christophe Pettus <xof@thebuild.com>, "David G. Johnston" <david.g.johnston@gmail.com>, Matthias Kurz <m.kurz@irregular.at>, Jim Nasby <Jim.Nasby@bluetreble.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-04-24T18:44:22Z
Lists: pgsql-hackers

Attachments


On 04/02/2016 01:20 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Looking at this briefly. It looks like the check should be called from
>> enum_in() and enum_recv(). What error should be raised if the enum row's
>> xmin isn't committed? ERRCODE_FEATURE_NOT_SUPPORTED? or maybe
>> ERRCODE_DATA_EXCEPTION? I don't see anything that fits very well.
> ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE is something we use in some
> other places where the meaning is "just wait awhile, dude".  Or you
> could invent a new ERRCODE.
>
> 			




OK, did that. Here is a patch that is undocumented but I think is 
otherwise complete. It's been tested a bit and we haven't been able to 
break it. Comments welcome.

cheers

andrew

Commits

  1. Relax transactional restrictions on ALTER TYPE ... ADD VALUE (redux).

  2. Partially restore comments discussing enum renumbering hazards.

  3. Allow adding values to an enum type created in the current transaction.