Re: WIP: extensible enums

On 10/17/2010 01:20 PM, Tom Lane wrote:
> I knew I shoulda read this patch ;-).  That seems a lot more invasive
> than this feature justifies.  And I share your qualms about whether it's
> race-condition-proof.  We don't have very much locking on pg_type
> entries, so making a hard assumption about consistency between two
> different catalogs seems pretty risky.
>
> The way I'd be inclined to design this is that altering an enum doesn't
> change its pg_type entry at all, just add another row to pg_enum.
> When first needing to compare values of an enum, load up the typcache
> entry for it.  This involves scanning all the entries for that type OID
> in pg_enum, and determining from that whether you can compare the easy
> way or not.  If not, build the array that tells you how to sort, and put
> it in the typcache entry.


Perhaps mistakenly I wanted to avoid doing that as it would slow down a 
retail comparison quite a lot, especially in the case of an enum with a 
very large label set. That's why I put the sorted property and label 
count in pg_type.


cheers

andrew