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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: checking variadic "any" argument in parser - should be array
Date: 2013-07-16 16:41:25
Message-ID: CAFj8pRAQygA7vLPwmKjX_r=b7bAGyjXM8YwNvAap6VK77iz1UQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/7/15 Andrew Dunstan <andrew(at)dunslane(dot)net>:
>
> On 07/14/2013 12:28 AM, Pavel Stehule wrote:
>>
>> Hello
>>
>> 2013/7/14 Andrew Dunstan <andrew(at)dunslane(dot)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
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ants Aasma 2013-07-16 16:46:20 Re: Improvement of checkpoint IO scheduler for stable transaction responses
Previous Message Tom Lane 2013-07-16 16:05:00 Re: Differences in WHERE clause of SELECT