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

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

              http://archives.postgresql.org

Reply via email to