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
|
Список | 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 по дате отправления: