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

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: checking variadic "any" argument in parser - should be array
Дата
Msg-id 51E45EF7.4090404@dunslane.net
обсуждение исходный текст
Ответ на Re: checking variadic "any" argument in parser - should be array  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: checking variadic "any" argument in parser - should be array  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On 07/14/2013 12:28 AM, Pavel Stehule wrote:
> 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


Quite so, I understand exactly what the defined behaviour will be.


>
> 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 only question I raised was for the NULL case. If you're not saying 
"VARIADIC NULL" then I have no issue.

Anyway, nobody else seem to care much (and I suspect very few people are 
writing VARIADIC "any" functions anyway, apart from you and me). So I'll 
see about getting this committed shortly.

cheers

andrew




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

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement)
Следующее
От: Noah Misch
Дата:
Сообщение: Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division]