Re: proposal: fix corner use case of variadic fuctions usage

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