Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
ANYENUM? What's the use-case for that?
Well ... *somebody* suggested it here ...
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00457.php
Well, in that usage (ie, for enum I/O functions) it's not actually
necessary that the type system as a whole understand ANYENUM as
"something that any enum type can be cast to", because you're going to
hot-wire the pg_type entries during CREATE ENUM anyway.
Well, it's not just I/O functions in pg_type, it's functions, operators,
aggregates, index methods etc. There are 34 OIDs used up by the enum
patch, and most of those catalog entries would have to be duplicated per
enum type by CREATE TYPE in the absence of ANYENUM; since you'd given
the hand-wavy suggestion anyway, it seemed better not to spam the catalogs.
Regarding the type system understanding ANYENUM, most of the type system
treats ANYENUM identically to ANYELEMENT, the only parts that really
need to understand it are the bits that try to tie down concrete types.
For those, non-enum types are rejected if the generic type is ANYENUM.
That's it, basically.
What I'm
wondering is if there's a use-case for it during ordinary user
operations with enums.
Not really. I allowed it to occur in plpgsql, mostly for completeness,
but I didn't bother for the other P/Ls as there didn't seem to be much
of a use case.
Cheers
Tom
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
