Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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