Re: Current enums patch

Andrew Dunstan wrote:
> Tom Lane wrote:
>> 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.
>
> Is this a tragedy when the supplied parameter gives the result type
> directly?

I've been having a play with this. If you create a function taking an
enum type as a parameter, you can feed the output from enum_first into
it, regardless of the type given to enum_first. I doubt that it would be
a problem in practice, but it's certainly not great.

> 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.

I don't think that'll fly. If it's passed a null value, how does
enum_first know which enum type it's dealing with? Can you get the type
from the null value in some way?

> 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.

That's ok, as long as nulls work.

> There might be other better ways, though. Thoughts?

*Ponder*. In java, you can tie a generic return value to a particular
class by passing the class in as a bound generic parameter... could we
have a special rule that would look for e.g. a regtype as the first
parameter if the return type is generic and there are no generic parameters?

As a side note, the helper functions were intended for people writing
functions in plpgsql or whatever, allowing them to not hardcode the
values of the enum in their function. I consider them nice-to-have
rather than definitely required. If we can't come up with a nice way to
do them for 8.3, I'm not absolutely wedded to them. It would be *nice*,
though.

I really would like the cast from text, though, but I'll deal with that
in another email.

Regards

Tom