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.
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
