2013/7/15 Andrew Dunstan <and...@dunslane.net>: > > On 07/14/2013 12:28 AM, Pavel Stehule wrote: >> >> Hello >> >> 2013/7/14 Andrew Dunstan <and...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers