Re: mixed, named notation support - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: mixed, named notation support
Date
Msg-id 162867790908041122meb13541xd84cc789cdfd8da8@mail.gmail.com
Whole thread Raw
In response to Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
Responses Re: mixed, named notation support  (Bernd Helmle <mailings@oopsware.de>)
List pgsql-hackers
2009/8/4 Bernd Helmle <mailings@oopsware.de>:
> --On Montag, August 03, 2009 23:43:08 +0200 Bernd Helmle
> <mailings@oopsware.de> wrote:
>
>> Status Report: I will finish documentation and review tomorrow and will
>> mark this patch for committer review.
>
> Here's my latest reviewed version of Pavel's patch with adjusted
> documentation per latest discussion.
>
> While poking a little bit with simplify_function() I realized that this
> patch changes the behavior of VARIADIC functions a little bit. For example:
>
> CREATE OR REPLACE FUNCTION my_test(a IN text, txt VARIADIC text[])
> RETURNS text
> AS
> $$
>  SELECT $2[1];
> $$ LANGUAGE SQL;
>
> The following doesn't work in current 8.4:
>
> SELECT my_test('abcd', ARRAY['test', 'foo']);
>
> You need to use the VARIADIC keyword to match the second argument to text[].
> However, if you are going to use named notation with the patch applied, the
> picture changes in HEAD:
>
> SELECT my_test('abcd' AS a, ARRAY['test', 'foo'] AS txt);
> my_test
> ---------
> test
> (1 row)
>
> This applies also when you reverse the argument order. I don't know wether
> this is intended, but its conflicting with what we have currently in the
> docs. It's also not clear to me wether we want this at all.
>

Named notation has different algorithm for function detection then
positional notation. There are not exist variadic parameters (because
these parameters hasn't individual names). So only "packed" variadic
parameter should be there, and this parameter have to be named  - so
keyword VARIADIC is optional.

Thank You very much
Pavel

> --
>  Thanks
>
>                   Bernd


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: the case for machine-readable error fields
Next
From: Alvaro Herrera
Date:
Subject: Re: the case for machine-readable error fields