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.
