Tom Dunstan <[EMAIL PROTECTED]> writes:
> 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
> 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.
Well, that's exactly the point: the proposed functions break the type
system by allowing values of one enum type to be fed to a function
expecting a different one. Even though that's unlikely to cause a
system crash, it's still wrong. We need to define these functions in a
way that allows type safety to be checked at parse time, the same as
every other type is required to be.
>>> 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?
The null Datum itself obviously doesn't carry that info, but the
expression tree does, and there are provisions for letting functions
retrieve that info --- see get_fn_expr_rettype and get_fn_expr_argtype.
It occurred to me this morning that get_fn_expr_rettype might
represent salvation for text_enum as well, though I've not tried
> ... 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?
I thought about that too but don't like it much. The problem is mainly
that it can only work for a constant regtype parameter.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly