Hi all! Thanks for reviewing the patch!

Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> 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.



1[] http://archives.postgresql.org/pgsql-hackers/2006-08/msg01022.php

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to