Re: checking variadic "any" argument in parser - should be array

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: checking variadic "any" argument in parser - should be array
Дата
Msg-id CAFj8pRDiRuCacVH2C4DFYy3F_528VvRot8+=h6m7BQL4h3+ZzA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: checking variadic "any" argument in parser - should be array  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: checking variadic "any" argument in parser - should be array  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
Hello

2013/7/14 Andrew Dunstan <andrew@dunslane.net>:
>
> On 06/29/2013 03:29 PM, Pavel Stehule wrote:
>
>
>
>>>>>> 5. This patch has user visibility, i.e. now we are throwing an error
>>>>>> when
>>>>>> user only says "VARIADIC NULL" like:
>>>>>>
>>>>>>      select concat(variadic NULL) is NULL;
>>>>>>
>>>>>> Previously it was working but now we are throwing an error. Well we
>>>>>> are
>>>>>> now
>>>>>> more stricter than earlier with using VARIADIC + ANY, so I have no
>>>>>> issue
>>>>>> as
>>>>>> such. But I guess we need to document this user visibility change. I
>>>>>> don't
>>>>>> know exactly where though. I searched for VARIADIC and all related
>>>>>> documentation says it needs an array, so nothing harmful as such, so
>>>>>> you
>>>>>> can
>>>>>> ignore this review comment but I thought it worth mentioning it.
>>>>>
>>>>> yes, it is point for possible issues in RELEASE NOTES, I am thinking
>>>>> ???
>>>>>
>>>> Well, writer of release notes should be aware of this. And I hope he
>>>> will
>>>> be. So no issue.
>
>
>
> Is the behaviour change really unavoidable? Is it really what we want?
> Nobody seems to have picked up on this except the author and the reviewer.
> I'd hate us to do this and then surprise people. I'm not sure how many
> people are using VARIADIC "any", but I have started doing so and expect to
> do so more, and I suspect I'm not alone.

It doesn't disallow NULL - it disallow nonarray types on this
possition, because there are must be only array type values. Other
possible usage created unambiguous behave.

so SELECT varfx(VARIADIC NULL) -- is disallowed
but SELECT varfx(VARIADIC NULL::text[]) -- is allowed

for example, I can wrote SELECT varfx(10,20,30), but I cannot write
SELECT varfx(VARIADIC 10,20,30) - because this behave should be
undefined.

Can me  send, your use case, where this check is unwanted, please.

The execution of variadic function can be little bit faster, because
this check is moved from execution to parser stage (and it is reason,
why I cannot to check NULL, because I have no simply access to
information about some parameter is constant or not.

It should to fix unwanted behave where VARIADIC keyword was ignored -
I am sure so this is some what we want, but I don't know your
arguments against, so please, send me you use case.

Regards

Pavel



>
> cheers
>
> andrew
>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: checking variadic "any" argument in parser - should be array
Следующее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: Patch to add support of "IF NOT EXISTS" to others "CREATE" statements