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