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

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> so here is rewritten patch

I've applied the infrastructure parts of this, but not the changes
to format() and concat().

Why are the format and concat patches so randomly different?
Not only is the internal implementation completely different for no
obvious reason, but the user-visible behavior is inconsistent too.
You've got one of them iterating over elements and one over slices.
That seems pretty bogus. Personally I'd vote for the element-level
behavior in both cases, because that's generally what happens in other
PG functions when there's no particular reason to pay attention to the
structure of a multidimensional array. I certainly don't see a reason
why they should be making opposite choices.

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().

BTW, using array_iterate as a substitute for deconstruct_array is
neither efficient nor good style. array_iterate is for processing the
values as you scan the array.

regards, tom lane