Skip site navigation (1) Skip section navigation (2)

Re: Current enums patch

From: Tom Dunstan <pgsql(at)tomd(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Current enums patch
Date: 2007-03-31 23:18:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
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 [1]. 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 DunstanDate: 2007-03-31 23:26:09
Subject: Re: Current enums patch
Previous:From: Bruce MomjianDate: 2007-03-31 23:13:20
Subject: Re: Macros for typtype (was Re: Arrays of Complex Types)

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group