Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-09-04 Thread Tom Lane
Emre Hasegeli writes: >> + /* >> +* If the row is hinted as committed, it's surely safe. This provides a >> +* fast path for all normal use-cases. >> +*/ >> + if (HeapTupleHeaderXminCommitted(enumval_tup->t_data)) >> + return; >> + >> + /* >> +*

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-09-04 Thread Emre Hasegeli
> Got around to looking at this. Attached is a revised version that I think > is in committable shape. The main non-cosmetic change is that the test > for "type was created in same transaction as new value" now consists of > comparing the xmins of the pg_type and pg_enum rows, without consulting

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-09-03 Thread Tom Lane
Andrew Dunstan writes: > 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. Got around to looking at this. Attached is a revised version that I think is

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-04-24 Thread Andrew Dunstan
On 04/02/2016 01:20 PM, Tom Lane wrote: Andrew Dunstan 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

Re: Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-04-02 Thread Tom Lane
Andrew Dunstan 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

Transactional enum additions - was Re: [HACKERS] Alter or rename enum value

2016-04-02 Thread Andrew Dunstan
On 03/29/2016 04:56 PM, Andrew Dunstan wrote: On 03/27/2016 10:20 AM, Tom Lane wrote: Andrew Dunstan writes: The more I think about this the more I bump up against the fact that almost anything we do might want to do to ameliorate the situation is going to be rolled