Re: Transactional enum additions - was Re: Alter or rename enum value - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Transactional enum additions - was Re: Alter or rename enum value
Date
Msg-id 571D1406.9070201@dunslane.net
Whole thread Raw
In response to Re: Transactional enum additions - was Re: Alter or rename enum value  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Transactional enum additions - was Re: Alter or rename enum value  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rename max_parallel_degree?
Next
From: Andres Freund
Date:
Subject: Ordering in guc.c vs. config.sgml vs. postgresql.sample.conf