Re: Issues for named/mixed function notation patch
От | Pavel Stehule |
---|---|
Тема | Re: Issues for named/mixed function notation patch |
Дата | |
Msg-id | 162867790909271046g149ecde3w82e86d554570aa7e@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Issues for named/mixed function notation patch (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Issues for named/mixed function notation patch
|
Список | pgsql-hackers |
2009/9/27 Robert Haas <robertmhaas@gmail.com>: > On Sun, Sep 27, 2009 at 12:37 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote: >>> "However, a named variadic argument can only be called the way shown in >>> the example above. The VARIADIC keyword must not be specified and a >>> variadic notation of all arguments is not supported. To use variadic >>> argument lists you must use positional notation instead." >>> >>> What is the intended behavior? I think we should always require VARIADIC >>> to be specified regardless of using named notation. >>> >> >> maybe we could to support variadic named parameters in future - then >> using VARIADIC keyword should be necessary - like >> >> foo(10 AS p1, 20 AS p1, 30 AS p3) is equalent of >> foo(VARIADIC ARRAY[10,20] AS p1, 30 AS p3) > > Pavel, > > This doesn't make sense to me, FWIW. I don't think we should allow > parameters to be specified more than once. It's hard for me to > imagine how that could be useful. ook I thing, so this should be little bit unclean too. I though why we need VARIADIC keyword mandatory for named notation. When we could specify only unique names, then we could use only one "packed" variadic parameter - and then VARIADIC keyword isn't necessary. Is this idea correct? I thing, so there are not problem ensure an using VARIADIC keyword in this context - but, personally I don't feel, so there it have to be. But I don't thing, so this is important (minimally for me) - I'll accept others opinions. Regards Pavel > >>> I'm still reviewing the code. > > Jeff, > > When will you be able to post this review? > > Thanks, > > ...Robert >
В списке pgsql-hackers по дате отправления: