| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Christophe Pettus <xof(at)thebuild(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Matthias Kurz <m(dot)kurz(at)irregular(dot)at>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Transactional enum additions - was Re: Alter or rename enum value |
| Date: | 2016-04-24 18:44:22 |
| Message-ID: | 571D1406.9070201@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04/02/2016 01:20 PM, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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 | Content-Type | Size |
|---|---|---|
| transactional_enum-additions-v1x.patch | binary/octet-stream | 10.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2016-04-24 18:58:14 | Ordering in guc.c vs. config.sgml vs. postgresql.sample.conf |
| Previous Message | Tom Lane | 2016-04-24 18:42:53 | Re: Rename max_parallel_degree? |