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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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-23 15:17:11
Message-ID: CA+TgmoYPU4henJ8mt1zHYHkY_grndUhM4VYM8MtGEXBatrzvrw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Wed, Jan 23, 2013 at 2:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
>> what should be result of concat(variadic NULL::int[])
>> I enabled this use case, but what should be result?
>
> I think there are two somewhat defensible theories:
>
> (1) punt, and return NULL overall. So in this case the variadic
> function would act as if it were STRICT. That seems a bit weird though
> if the function is not strict otherwise.
>
> (2) Treat the NULL as if it were a zero-length array, giving rise to
> zero ordinary parameters. This could be problematic if the function
> can't cope very well with zero parameters ... but on the other hand,
> if it can't do so, then what will it do with VARIADIC '{}'::int[] ?
>
> I lean a little bit towards (2) but it's definitely a judgment call.
> Anybody have any other arguments one way or the other?

I'd like to vote for "it probably doesn't matter very much, so let's
just pick whatever makes the code simplest". :-)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2013-01-23 16:58:04 Re: proposal: fix corner use case of variadic fuctions usage
Previous Message Kevin Grittner 2013-01-23 14:45:49 Re: Running update in chunks?

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-01-23 15:18:50 Re: logical changeset generation v4
Previous Message Robert Haas 2013-01-23 15:14:51 Re: Prepared statements fail after schema changes with surprising error