Re: Initial review of xslt with no limits patch

2010/8/6 David E. Wheeler <david(at)kineticode(dot)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 new name 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
>
>
>