Re: WIP: extensible enums

On 10/24/2010 03:33 PM, Tom Lane wrote:
> Dean Rasheed<dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> The point with an OID array is that you wouldn't need to store the
>> enumsortorder values at all. The sort order would just be the index of
>> the OID in the array. So the comparison code would read the OID array,
>> traverse it building an array of enum_sort structs {oid, idx}, sort
>> that by OID and cache it.
> Hmm. But I guess we'd have to keep that array in the pg_type row,
> and it'd be a huge PITA to work with at the SQL level. For instance,
> psql and pg_dump can easily be adapted to use enumsortorder instead
> of pg_enum.oid when they want to read out the labels in sorted order.
> Doing the same with an array representation would be a very different
> and much uglier query. I'm not eager to contort the catalog
> representation that much.

If that's the only objection I don't know that it's terribly serious.
psql and pg_dump could sanely use something like:

select enum_oid, row_number() over () as sort_order
from unnest(null::myenum) as enum_oid

That said, I'm generally wary of array fields, especially in the catalog.

cheers

andrew