From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: alter enum add value if not exists |
Date: | 2012-08-23 10:47:36 |
Message-ID: | CABUevExBqNKjvcH9CTLfMV5HkV5UuGyMwazc=Ss3ps0+6=8qgQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> Here is a patch for this feature, which should alleviate some of the woes
> caused by adding labels not being transactional (and thus not allowing for
> the catching of errors).
I haven't actually checked the code in detail, but if it's not
transactional, how does it actually prevent race conditions? Doesn't
it at least have to do it's check *after* the enum is locked?
I don't recall the exact discussion, but was there something about
enum labels that made it impossible to make them transactional, or was
it just "lots of work, let's do that later instead" to get the feature
in? If the second, does anyone have plans to fix it? It is a quite
annoying limitation :(
That said, this functionality would be useful even *if* the enum label
addition was made transactional...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2012-08-23 11:09:51 | Re: to_timestamp() too loose? |
Previous Message | Magnus Hagander | 2012-08-23 10:40:33 | Re: pg_stat_replication vs StandbyReplyMessage |