BTW, I've got fairly serious problems with a few of the "cuter" parts of
the patch:
enum_first, enum_last: these return ANYENUM but violate the rule that
a polymorphic-result function must have a polymorphic input argument
from which the parser may deduce the actual output type.
enum_range_all: same problem except ANYARRAY result.
text_enum: same problem as above, plus not acceptable to assume that it
gets the right enum OID, plus very definitely not acceptable to assume
that OID and typmod are the same size, plus I don't like the
undocumented kluge in getBaseTypeAndTypmod that is pretending to supply
the type OID for some small fraction of possible invocation cases.
I think text_enum is probably toast. We might be able to salvage the
other three if we can think of some reasonable approach to type
determination. One rather ugly possibility is that the argument is a
value of the target type --- which you can always have as null, so
enum_first(null::rainbow) = 'red'
where enum_first is declared as taking and returning anyenum. This
seems a bit yucky as opposed to the regtype approach in the patch,
and yet there are cases where it would be more handy --- eg, if
you are working with a table column "col" of some enum type, you
can do enum_first(col) instead of hardwiring the enum name.
There might be other better ways, though. Thoughts?
regards, tom lane
