Hello
2013/1/22 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@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
variadic_any_fix_20130122.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
