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

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: proposal: fix corner use case of variadic fuctions usage
Дата
Msg-id CAFj8pRBbK15fBNVdWB_r6d5JRxm3i4QEHxrb7dsvLyGdJBp+ig@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: fix corner use case of variadic fuctions usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: fix corner use case of variadic fuctions usage  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hello

I sent a updated patch, but still I am not sure in one topic


> 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().

what should be result of concat(variadic NULL::int[])

I enabled this use case, but what should be result?

usually concat() function needs one parameter as minimum and then
returns empty string or some string. But concat(variadic NULL::int[])
is +/- zero parameters call. A result should be empty string or NULL?

I am vote returning NULL and I have a only one argument

If concat(variadic NULL::int[]) returns NULL, then it returns
different "value" than concat(variadic '{}'::int[]) what is correct.
Opposite behave returns empty string in both variants and It is some
when I don't feel well.

Regards

Pavel



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Craig Ringer
Дата:
Сообщение: Re: Visual Studio 2012 RC
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: fix corner use case of variadic fuctions usage