> OK, I stand corrected, although I'm not totally convinced. I still
> think to_array() and to_string() are not a good choice of names. I am
> not sure if we should reuse the existing names (adding a third
> parameter) or pick something else, like array_concat() and
> split_to_array().
>
It was discussed before. I would to see some symmetry in names. The
bad thing is so great names like string_to_array and array_to_string
is used, and second bad thing was done three years ago when nobody
thinking about NULL values. I don't think, so we are able to repair
older functions - simply the default behave isn't optimal.
I am thinking so we have to do decision about string_to_array and
array_to_string deprecation first. If these function will be
deprecated, then we can use a similar names (and probably we should to
use a similar names) - so text_to_array or array_to_string can be
acceptable. If not, then this discus is needless - then to_string and
to_array have to be maximally in contrib - stringfunc is good idea -
and maybe we don't need thinking about new names.
> Also, should we consider putting these in contrib/stringfunc rather
> than core? Or is there enough support for core that we should stick
> with doing it that way?
>
so it is one variant. I am not against to moving these function to
contrib/stringfunc.
I am thinking, so we have to solve question about marking
string_to_array and array_to_string functions as deprecated first.
Then we can move forward?? My opinion is known - I am for removing of
these function in future and replacing by modernized functions.
Others opinions???
Can we move forward?
Regards
Pavel
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>