From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: patch: General purpose utility functions used by the JSON data type |
Date: | 2010-08-13 20:42:13 |
Message-ID: | 4C65AE25.4010504@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/13/2010 03:46 PM, Joseph Adams wrote:
> On Fri, Aug 13, 2010 at 2:02 PM, David Fetter<david(at)fetter(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2010-08-13 21:47:47 | Window functions seem to inhibit push-down of quals into views |
Previous Message | Josh Berkus | 2010-08-13 20:29:11 | Re: WIP partial replication patch |