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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Vik Reykja <vikreykja(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: fix corner use case of variadic fuctions usage
Date: 2013-01-22 03:00:27
Message-ID: 5992.1358823627@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-22 03:08:38 Re: dividing privileges for replication role.
Previous Message Phil Sorber 2013-01-22 02:27:55 Re: CF3+4 (was Re: Parallel query execution)

Browse pgsql-general by date

  From Date Subject
Next Message Gavan Schneider 2013-01-22 03:40:04 Re: Yet Another Timestamp Question: Time Defaults
Previous Message Mihai Popa 2013-01-22 02:49:46