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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
