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-23 16:58:04
Message-ID: 21285.1358960284@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:
> next related example

> CREATE OR REPLACE FUNCTION public.myleast(VARIADIC integer[])
> RETURNS integer
> LANGUAGE sql
> AS $function$
> select min(v) from unnest($1) g(v)
> $function$

The reason you get a null from that is that (1) unnest() produces zero
rows out for either a null or empty-array input, and (2) min() over
zero rows produces NULL.

In a lot of cases, it's not very sane for aggregates over no rows to
produce NULL; the best-known example is that SUM() produces NULL, when
anyone who'd not suffered brain-damage from sitting on the SQL committee
would have made it return zero. So I'm not very comfortable with
generalizing from this specific case to decide that NULL is the
universally right result.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Alexander Law 2013-01-23 17:06:01 Re: BUG #6510: A simple prompt is displayed using wrong charset
Previous Message Robert Haas 2013-01-23 15:17:11 Re: proposal: fix corner use case of variadic fuctions usage

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2013-01-23 16:58:28 Re: [COMMITTERS] pgsql: Improve concurrency of foreign key locking
Previous Message Robert Haas 2013-01-23 16:50:22 Re: Prepared statements fail after schema changes with surprising error