Re: WIP: extensible enums

On 10/17/2010 03:17 PM, Tom Lane wrote:
> Dean Rasheed<dean.a.rasheed@gmail.com>  writes:
>> On 17 October 2010 18:53, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>>> We could fix that with Dean's idea of reloading the cache whenever
>>> we see that we are being asked to compare a value we don't have in the
>>> cache entry.  However, that assumes that we even notice that it's not
>>> in the cache entry.  If we're trying to use "fast" comparison then we
>>> wouldn't notice that.
>> That makes me think maybe the "fast" and "slow" comparisons should
>> both be done the same way, having a cache so that we notice
>> immediately if we get a new value.
> Actually ... the race conditions can be a lot worse than just a race.
> Consider
>
>     begin;
>     alter type myenum add 'some-value';
>     insert into mytab values('some-value');
>     rollback;
>
> If mytab has an index on the enum col, we now have an index entry that
> contains an enum value that isn't valid according to anybody, and nobody
> knows how to compare it.  If that entry is near the root then the index
> is hopelessly corrupt: no one can tell which way to descend when
> comparing it to some valid value.
>
> I think what this says is that we cannot allow any manipulations that
> involve an uncommitted enum value.  Probably the easiest way is to make
> the ALTER TYPE operation disallowed-inside-transaction-block.  That's
> pretty ugly, but doesn't seem like a serious restriction in practice
> (though for example it'd mean we couldn't use it in pg_dump).

Even in binary upgrade mode?

cheers

andrew