On 08/23/2012 06:47 AM, Magnus Hagander wrote:
On Mon, Aug 20, 2012 at 4:52 PM, Andrew Dunstan <and...@dunslane.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?
Well, you can't remove a label, and if the test succeeds it results in
your doing nothing, so my possibly naive thinking was that that wasn't
necessary. But I could easily be wrong :-)
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 :(
I don't know of any plans to fix it.
That said, this functionality would be useful even *if* the enum label
addition was made transactional...
Right.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
