Re: RfD: more powerful "any" types

2009/9/9 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> Well, so far we've only seen use cases in this thread that either
>> already work or that are not well-defined. ;-)
>
> Well, yeah, the question is can we extract a clear TODO item here.
>
> I think there are two somewhat orthogonal issues:
>
> 1. Is a completely unconstrained argument type (ie "any") of any real
> use to PL functions, and if so how can we expose that usefulness?
> The only clear thing to do with such an argument is IS NULL/IS NOT NULL
> tests, which might or might not be worth the trouble.
>
> 2. Is there any use for arguments with type constraints not covered
> by the existing ANYFOO rules, and if so what do we add for that?
>
> One comment on point 2 is that it was foreseen from the beginning
> that there would be need for ANYELEMENT2 etc, and I'm actually rather
> surprised that we've gone this long without adding them.  Alvaro made
> a good point about not wanting to multiply the various hard-wired
> OID references, but perhaps some judicious code refactoring could
> prevent a notational disaster.

I hope so 2 independent polymorphic types are enough. The bigger
problem is coexistence 'unknown' type and anyelement type. Simply we
cannot to write equivalent coalesce, nullif functions vith only
polymorphic types, because we cannot to force implicit casting
unknown->text.

maybe we could to add new function hint "unknown to some"

CREATE OR REPLACE FUNCTION coalesce(VARIADIC anyelement[])
RETURNS anyelement AS $$
SELECT $1[i]
FROM generate_subscripts($1) g(i)
WHERE $1[i] IS NOT NULL
$$ LANGUAGE sql UNKNOWN IS text;

???
Regards
Pavel Stehule

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>