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;
>> +
>> + /*
>> +* Usually, a row would ge
> 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
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 in committable shape.
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
ERRCODE_DATA_EXCEPTION?
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 anything that fits ver
