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

Hello

2013/1/22 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.

I updated patch

* simplify concat and concat_ws with reuse array_to_text_internal
* remove support for slicing (multidimensional arrays)
* VARIADIC NULL is allowed

Regards

Pavel

>
> regards, tom lane