2010/7/21 Robert Haas <robertmhaas@gmail.com>:
> On Wed, Jul 21, 2010 at 9:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>> It was discussed before. I would to see some symmetry in names.
>
> That's reasonable.
>
>> The
>> bad thing is so great names like string_to_array and array_to_string
>> is used,
>
> Yeah, those names are not too good.
>
>> 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.
>
> This is a matter of opinion, but certainly it's not right for everyone.
>
>> 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.
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>