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
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? |
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 |