On Thu, 2009-09-10 at 00:31 +0200, Dimitri Fontaine wrote:
> Hi,
>
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > Hannu Krosing <hannu@2ndQuadrant.com> writes:
> >> anyelement(1), anyelement(2), ..., anyelement(N) and then match them by
> >> the number in parentheses
> >
> > Yeah, that idea occurred to me too. The immediate practical problem is
> > that we don't store a typmod for function argument/result types.
> > I guess we could look into doing that ...
>
> But still, it looks terrible...
>
> On Sep 9, 2009, at 4:44 AM, Peter Eisentraut wrote:
> > That's beginning to sound a bit like a generics feature. E.g.,
> >
> > CREATE FUNCTION the_same<T>(arg_a T, arg_b T) RETURNS bool AS $$
> > SELECT arg_a IS DISTINCT FROM arg_b;
> > $$;
>
> And even if we don't want to go this far (I'd be in favor of going there
> FWIW), we could maybe have a syntax allowing the users to name or
> declare the any types he'll need?
>
> CREATE FUNCTION foo(a anyelement x, b anyelement x, c anyelement y)
> RETURNS anyelement y[]
> AS $$
> ...
> $$;
>
> Now we have anyelement and anyelement2, but without the ugly names or
> the typmod feature stretching, and we can even have any number of user
> defined anyelement types. That behave just like anyelement.
>
> Then, maybe we need VARIADIC anyelement any[] to declare the function as able
> to cope with a variable length list of all different kinds of elements?
maybe just let users say what they mean, so first time we have "any" and
if we need more then we say "same_as(...)"
so your example becomes
CREATE FUNCTION foo(a any, b same_type_as(a), c any) RETURNS same_type_as(c)[]AS $$... $$;
or the same using positional arguments
CREATE FUNCTION foo(a any, b same_type_as(1), c any) RETURNS same_type_as(3)[]AS $$... $$;
this then gets transformed at parse time to whatever internal
representation of type sameness we use.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
