Hello
I sent a updated patch, but still I am not sure in one topic
> Also, I'm not sure that it's appropriate to throw an error if the given
> argument is null or not an array. Previous versions did not throw an
> error in such cases. Perhaps just fall back to behaving as if it
> weren't marked VARIADIC? You could possibly make an argument for
> not-an-array-type being an error, since that's a statically inconsistent
> type situation, but I really don't like a null value being an error.
> A function could easily receive a null value for an array parameter
> that it wants to pass on to format() or concat().
what should be result of concat(variadic NULL::int[])
I enabled this use case, but what should be result?
usually concat() function needs one parameter as minimum and then
returns empty string or some string. But concat(variadic NULL::int[])
is +/- zero parameters call. A result should be empty string or NULL?
I am vote returning NULL and I have a only one argument
If concat(variadic NULL::int[]) returns NULL, then it returns
different "value" than concat(variadic '{}'::int[]) what is correct.
Opposite behave returns empty string in both variants and It is some
when I don't feel well.
Regards
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
