Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
ANYENUM?  What's the use-case for that?

Well ... *somebody* suggested it here ...

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.



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

Reply via email to