2010/8/6 David E. Wheeler <david@kineticode.com>:
> On Aug 6, 2010, at 1:49 PM, Pavel Stehule wrote:
>
>> yes it is one a possibility and probably best. The nice of this
>> variant can be two forms like current variadic does - foo(.., a :=
>> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
>
> I started fiddling and got as far as this:
>
>
> CREATE TYPE pair AS ( key text, val text );
>
> CREATE OR REPLACE FUNCTION pair(anyelement, anyelement) RETURNS pair
> LANGUAGE SQL AS $$
> SELECT ROW($1, $2)::pair;
> $$;
>
> CREATE OR REPLACE FUNCTION pair(text, text) RETURNS pair
> LANGUAGE SQL AS $$
> SELECT ROW($1, $2)::pair;
> $$;
>
> CREATE OPERATOR ~> (
> LEFTARG = anyelement,
> RIGHTARG = anyelement,
> PROCEDURE = pair
> );
>
> CREATE OPERATOR ~> (
> LEFTARG = text,
> RIGHTARG = text,
> PROCEDURE = pair
> );
>
> CREATE OR REPLACE FUNCTION foo(variadic pair[]) RETURNS SETOF text
> LANGUAGE SQL AS $$
> -- SELECT unnest($1)::text
> SELECT $1[1].key
> UNION SELECT $1[1].val
> UNION SELECT $1[2].key
> UNION SELECT $1[2].val;
> $$;
>
> SELECT foo('this' ~> 'that', 1 ~> 4);
>
> Not bad, I think. I kind of like it. It reminds me how much I hate the % hstore construction operator, though (the
newname for =>).
so there is only small step to proposed feature
SELECT foo(this := 'that', "1" := 4)
there is only one difference (but you cannot implement it now)
* notation for key is same like for sql identifier - why: I would to
clearly identify key and value. When I use a custom operator - like
you did, it depends on implementation what is key, what is value. When
you use a SQL identifier's notation for key, you can't to do a error
Regards
Pavel
>
> Best,
>
> David
>
>
>