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 по дате отправления: