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.
Joey Adams