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

sorry

I have to change  wrong comment

Regards

Pavel

2013/1/22 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
>
>
> 2013/1/22 Tom Lane <tgl@sss.pgh.pa.us>:
>> Pavel Stehule <pavel.stehule@gmail.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