Re: patch: to_string, to_array functions

2010/7/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>> 2010/7/21 Robert Haas <robertmhaas(at)gmail(dot)com>:
>>> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
>>> <itagaki(dot)takahiro(at)gmail(dot)com> wrote:
>>>> 2010/7/20 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>>>> here is a new version - new these functions are not a strict and
>>>>> function to_string is marked as stable.
>>>>
>>>> We have array_to_string(anyarray, text) and string_to_array(text, text),
>>>> and you'll introduce to_string(anyarray, text, text) and
>>>> to_array(text, text, text).
>>>> Do we think it is good idea to have different names for them?  IMHO, we'd
>>>> better  use 3 arguments version of array_to_string() instead of the
>>>> new to_string() ?
>>>
>>> The worst part is that the new names are not very mnemonic.
>>>
>>> I think maybe what we really need here is array equivalents of
>>> COALESCE() and NULLIF().  It looks like the proposed to_string()
>>> function is basically equivalent to replacing each NULL entry with the
>>> array with a given value, and then doing array_to_string() as usual.
>>> And it looks like the proposed to_array function basically does the
>>> same thing as to_array(), and then replaces empty strings with NULL or
>>> some other value.
>>>
>>> Maybe we just need a function array_replace(anyarray, anyelement,
>>> anyelement) that replaces any element in the array that IS NOT
>>> DISTINCT FROM $2 with $3 and returns the new array.  That could be
>>> useful for other things besides this particular case, too.
>>
>> I don't agree. Building or updating any array is little bit expensive.
>> There can be same performance issue like combination array_agg and
>> array_to_string versus string_agg.
>
> But is it really bad enough to introduce custom versions of every
> function that might want to do this sort of thing?
>
>> I am not against to possible name
>> changes. But I am strong in opinion so current string_to_array and
>> array_to_string are buggy and have to be deprecated.
>
> But I don't think anyone else agrees with you.  The current behavior
> isn't the only one anyone might want, but it's one reasonable
> behavior.

see on discus to these function - this is Marlin Moncure proposal

http://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg151503.html

these functions was designed in reaction to reporting bugs and
problems with serialisation and deserialisation of arrays with null
fields.

you can't to parse string to array with null values now

postgres=# select string_to_array('1,2,3,null,5',',')::int[];
ERROR: invalid input syntax for integer: "null"
postgres=#

Regards

Pavel Stehule
>
>> p.s. can we use a names - text_to_array, array_to_text ?
>
> That's not going to reduce confusion one bit...
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise Postgres Company
>