Re: checking variadic "any" argument in parser - should be array - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: checking variadic "any" argument in parser - should be array
Date
Msg-id CAFj8pRAQygA7vLPwmKjX_r=b7bAGyjXM8YwNvAap6VK77iz1UQ@mail.gmail.com
Whole thread Raw
In response to Re: checking variadic "any" argument in parser - should be array  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
2013/7/15 Andrew Dunstan <andrew@dunslane.net>:
>
> 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.

NULL is allowed - but it should be typed.

>
> 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.
>

exactly

Regards

Pavel

> cheers
>
> andrew
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Differences in WHERE clause of SELECT
Next
From: Ants Aasma
Date:
Subject: Re: Improvement of checkpoint IO scheduler for stable transaction responses