Re: patch: to_string, to_array functions

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: patch: to_string, to_array functions
Дата
Msg-id AANLkTimCBajPRWKpD1KzGvx+N6ybtaXPbOe5-Lwp=kKk@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: to_string, to_array functions  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
Hello Dimitry

>>
>> I still don't see a compelling reason not to extend existing functions
>> with a third argument. Or are we talking about deprecating them in the
>> future (like remove their mention in the docs) and have the new names to
>> replace them, with the new behavior as the default and the extended call
>> convention as the old behavior?
>
> just incomplete default behave :(. We can enhance old functions, but
> we cannot to change default behave - it is mean, so we will to ignore
> a NULLs in arrays forever - but it isn't true a three years. It is a
> feature now. Please look to archive. There was a discus about it.
>

The reason, why I am strong in change of default behave is only one -
I know only one use-case for curent behave - when array_to_string
ignore a NULL, - when you would to remove NULLs from array, you can do
string_to_array(array_to_string(x,'###'), '###') - I don't know other
use-case. When I have a NULL in array, then it have a some sense
there. And I can remove NULLs from array via more secure and faster
way

SELECT array(SELECT v FROM unnest(x) g(x) WHERE v IS NOT NULL)

using string_to_array and array_to_string is slower and for some
domains can be wrong (for text).

Regards

Pavel

p.s. I expect so anybody who has NULLs in an array not only for a joy.


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: patch: to_string, to_array functions
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Rewrite, normal execution vs. EXPLAIN ANALYZE