| From: | Christophe Pettus <christophe(dot)pettus(at)pgexperts(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org, "David E(dot) Wheeler" <david(at)justatheory(dot)com> |
| Subject: | Re: BUG #14825: enum type: unsafe use? |
| Date: | 2017-09-25 17:32:08 |
| Message-ID: | 9C898B52-A75C-4CA1-84DD-8B89051DFEB2@pgexperts.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs pgsql-hackers |
> On Sep 25, 2017, at 07:55, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com> wrote:
> Let's ask a couple of users who I think are or have been actually
> hurting on this point. Christophe and David, any opinions?
Since about 90% of what I encounter in this area are automatically-generated migrations, having a clear set of (perhaps restrictive) rules which never fail is the most important. It's easy to split the CREATE or ALTERs out into their own transaction, and leave usage (such as populating a table from a migration) to a second transaction.
It's not clear to me that this is a vote either way, but I think the easiest thing to explain ("you cannot use a new enum value in the same transaction that created it") is the best in this situation.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David E. Wheeler | 2017-09-25 17:34:23 | Re: BUG #14825: enum type: unsafe use? |
| Previous Message | Petr Jelinek | 2017-09-25 17:22:52 | Re: Re: BUG #14785: Logical replication does not work after adding a column. Bug? |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2017-09-25 17:32:29 | Re: Built-in plugin for logical decoding output |
| Previous Message | Joshua D. Drake | 2017-09-25 17:31:26 | Re: Built-in plugin for logical decoding output |