On 10/24/2010 03:33 PM, Tom Lane wrote:
Dean Rasheed<dean.a.rash...@gmail.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
