On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: >>> 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. >> >> Well, -1 from me for deprecating string_to_array and array_to_string. >> >> I am not in favor of the names to_string and to_array even if we put >> them in contrib, though. The problem with string_to_array and >> array_to_string is that they aren't descriptive enough, and >> to_string/to_array is even less so. > > I am not a English native speaker, so I have a different feeling. > These functions do array_serialisation and array_deseralisation, but > this names are too long. I have not idea about better names - it is > descriptive well (for me) text->array, array->text - and these names > shows very cleanly symmetry between functions. I have to repeat - it > is very clean for not native speaker.
Well, the problem is that array_to_string(), for example, tells you that an array is being converted to a string, but not how. And to_string() tells you that you're getting a string, but it doesn't tell you either what you're getting it from or how you're getting it. We already have a function to_char() which can be used to format a whole bunch of different types as strings; I can't see adding a new function with almost the same name that does something completely different. array_split() and array_join(), following Perl? array_implode() and array_explode(), along the lines suggested by Brendan? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers