Hi all! Thanks for reviewing the patch!
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> Tom Lane wrote:
>>> Is there a specific reason for
>>> pg_enum.enumname to be type name and not type text?
>> IIRC at one stage Tom wanted to try to make these identifiers, but that
>> was quickly abandoned. This might be a hangover from that.
> Actually I think I see the reason: it's a bit of a pain in the neck to
> use the syscache mechanism with text-type lookup keys. I'm not 100%
> convinced that we really need to have syscaches on pg_enum, but if those
> stay then it's probably not worth the trouble to avoid the limitation.
Yeah, that was the reason IIRC. The syscaches are used by the I/O
functions: The one keyed on the pg_enum OID is for output, and the one
keyed on the type OID and label, err, name, are for input. As suggested
by a certain party here . There didn't seem to be any text-like key
types to use in the syscache except the name type, and I didn't see the
63 byte limit being a big deal, that's way bigger than any sane enum
name that I've ever seen.
If we ditched the second syscache, we'd want some other way to convert a
type OID and name into the enum value oid efficiently. I originally
suggested having a cache that got hooked onto an fn_extra field; that
idea could be resurrected if you don't like the syscache.
In response to
pgsql-patches by date
|Next:||From: Tom Dunstan||Date: 2007-03-31 23:26:09|
|Subject: Re: Current enums patch|
|Previous:||From: Bruce Momjian||Date: 2007-03-31 23:13:20|
|Subject: Re: Macros for typtype (was Re: Arrays of Complex