Re: Alter or rename enum value

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
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: Alter or rename enum value
Date: 2016-03-27 14:20:27
Message-ID: 4075.1459088427@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> The more I think about this the more I bump up against the fact that
> almost anything we do might want to do to ameliorate the situation is
> going to be rolled back. The only approach I can think of that doesn't
> suffer from this is to abort if an insert/update will affect an index on
> a modified enum. i.e. we prevent the possible corruption from happening
> in the first place, as we do now, but in a much more fine grained way.

Perhaps, instead of forbidding ALTER ENUM ADD in a transaction, we could
allow that, but not allow the new value to be *used* until it's committed?
This could be checked cheaply during enum value lookup (ie, is xmin of the
pg_enum row committed).

What you really need is to prevent the new value from being inserted
into any indexes, but checking that directly seems far more difficult,
ugly, and expensive than the above.

I do not know whether this would be a meaningful improvement for
common use-cases, though. (It'd help if people were more specific
about the use-cases they need to work.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-03-27 14:40:03 Re: AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()
Previous Message Alexander Korotkov 2016-03-27 13:31:02 Re: Move PinBuffer and UnpinBuffer to atomics