From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
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-15 20:43:35 |
Message-ID: | 51E45EF7.4090404@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2013-07-15 21:59:22 | Re: FILTER for aggregates [was Re: Department of Redundancy Department: makeNode(FuncCall) division] |
Previous Message | Fabien COELHO | 2013-07-15 19:02:36 | Re: [PATCH] pgbench --throttle (submission 7 - with lag measurement) |