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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
