<br /><br /> On 10/24/2010 03:33 PM, Tom Lane wrote: <blockquote cite="mid:15783.1287948822@sss.pgh.pa.us"
type="cite"><prewrap="">Dean Rasheed <a class="moz-txt-link-rfc2396E"
href="mailto:dean.a.rasheed@gmail.com"><dean.a.rasheed@gmail.com></a>writes:
</pre><blockquote type="cite"><pre wrap="">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.
</pre></blockquote><pre wrap="">
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.
</pre></blockquote><br /> If that's the only objection I don't know that it's terribly serious. psql and pg_dump could
sanelyuse something like:<br /><blockquote>select enum_oid, row_number() over () as sort_order<br /> from
unnest(null::myenum)as enum_oid<br /><br /></blockquote> That said, I'm generally wary of array fields, especially in
thecatalog.<br /><blockquote></blockquote> cheers<br /><br /> andrew<br /><br /><br />