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