On 08/13/2010 03:46 PM, Joseph Adams wrote:
> On Fri, Aug 13, 2010 at 2:02 PM, David Fetter<david@fetter.org> wrote:
>> On Fri, Aug 13, 2010 at 01:33:06PM -0400, Robert Haas wrote:
>>> Maybe so, but it's not clear the interface that Joseph implemented is
>>> the one everyone wants...
>> Fair enough. What's the interface now in a nutshell? Lack of
>> nutshells might well mean the interface needs more work...
> Suppose we have:
>
> -- SQL --
> CREATE TYPE colors AS ENUM ('red', 'green', 'blue');
>
> -- C --
> enum Colors {RED, GREEN, BLUE, COLOR_COUNT};
>
> In a nutshell:
>
> * Define an enum mapping like so:
>
> static EnumLabel enum_labels[COLOR_COUNT] =
> {
> {COLOR_RED, "red"},
> {COLOR_GREEN, "green"},
> {COLOR_BLUE, "blue"}
> };
>
> * Get the OIDs of the enum labels:
>
> Oid oids[COLOR_COUNT];
> getEnumLabelOids("colors", enum_labels, oids, COLOR_COUNT);
>
> * Convert C enum values to OIDs using the table:
>
> PG_RETURN_OID(oids[COLOR_BLUE]);
>
> A caller would typically cache the Oid table with fn_extra.
>
> Currently, getEnumLabelOids puts InvalidOid for labels that could not
> successfully be looked up. This will probably be changed to
> ereport(ERROR) instead.
>
> Also, I'm thinking that getEnumLabelOids should be renamed to
> something that's easier to remember. Maybe enum_oids or
> get_enum_oids.
>
>
>
I should point out that I'm hoping to present a patch in a few weeks for
extensible enums, along the lines previously discussed on this list. I
have only just noticed this thread or I would have jumped in earlier.
Maybe what I'm doing won't impact much on this - it does cache enum oids
and their associated sort orders in the function context, but lazily -
the theory being that a retail comparison should not have to look up the
whole of a large enum set just to get two sort order values.
cheers
andrew