From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Christophe Pettus <xof@thebuild.com>,
        "David G. Johnston" <david.g.johnston@gmail.com>,
        Matthias Kurz <m.kurz@irregular.at>,
        Jim Nasby <Jim.Nasby@bluetreble.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Alter or rename enum value
In-reply-to: <56F7D8BF.5000000@dunslane.net>
References: 
 <CAO=2mx6uvgPaPDf-rHqG8=1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com>
 <56E049CC.8010201@dunslane.net> <25605.1457539654@sss.pgh.pa.us>
 <56E05635.70908@dunslane.net> <28167.1457543612@sss.pgh.pa.us>
 <CAO=2mx4rQHRvifT2yUQ1rz90A=9CVz4_Z0Sx1wTgwgQRzAimpQ@mail.gmail.com>
 <CAO=2mx6rK_h4BC7y+3Nu-8fuZJXdFjd9FE_MZnzkH+vnMp0C-Q@mail.gmail.com>
 <d8ja8ln7nl0.fsf@dalvik.ping.uio.no> <d8j60wb7na4.fsf@dalvik.ping.uio.no>
 <CAO=2mx6CgQXFJYXOpr4OJO+r8WX6PzEU5aT+K0vV94G7DxVJ0A@mail.gmail.com>
 <56F49CF8.8050007@BlueTreble.com> <27476.1458876456@sss.pgh.pa.us>
 <CAO=2mx6EOh6uQQ57Kv2z0x=kuyVbkEbwiY8R2h6VCPL=Fxe5wg@mail.gmail.com>
 <56F58876.6020508@dunslane.net>
 <CAKFQuwZeVdo=qQy-WV_hfqy0Wsit9tuhtZOLsq1Jx82eKc8bfQ@mail.gmail.com>
 <56F6827F.9040104@dunslane.net> <3202.1459002341@sss.pgh.pa.us>
 <56F69F5C.1060408@dunslane.net>
 <B9E6AF60-A402-4388-BE5A-BD078F3A3155@thebuild.com>
 <56F7D8BF.5000000@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Sun, 27 Mar 2016 08:57:35 -0400"
Date: Sun, 27 Mar 2016 10:20:27 -0400
Message-ID: <4075.1459088427@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andrew Dunstan <andrew@dunslane.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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers