Re: Current enums patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tom Dunstan <pgsql(at)tomd(dot)cc>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Current enums patch
Date: 2007-04-01 18:42:52
Message-ID: 15940.1175452972@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Tom Dunstan <pgsql(at)tomd(dot)cc> 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
>> 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.

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

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

In response to

Responses

Browse pgsql-patches by date

  From Date Subject
Next Message Peter Eisentraut 2007-04-01 20:18:57 Re: Macros for typtype (was Re: Arrays of Complex Types)
Previous Message Tom Lane 2007-04-01 18:31:41 Re: Macros for typtype (was Re: Arrays of Complex Types)