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

2013/1/23 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 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.
>

I am testing some situation and there are no consistent idea - can we
talk just only about functions concat and concat_ws?

these functions are really specific - now we talk about corner use
case and strongly PostgreSQL proprietary solution. So any solution
should not too bad.

Difference between all solution will by maximally +/- 4 simple rows
per any function.

Possibilities

1) A. concat(variadic NULL) => empty string, B. concat(variadic '{}')
=> empty string -- if we accept @A, then B is ok
2) A. concat(variadic NULL) => NULL, B. concat(variadic '{}') => NULL
-- question - is @B valid ?
3) A. concat(variadic NULL) => NULL, B. concat(variadic '{}) => empty string

There are no other possibility.

I can live with any variant - probably we find any precedent to any
variant in our code or in ANSI SQL.

I like @2 as general concept for PostgreSQL variadic functions, but
when we talk about concat() and concat_ws() @1 is valid too.

Please, can somebody say his opinion early

Regards

Pavel

> regards, tom lane