Re: patch: to_string, to_array functions

2010/7/21 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
> 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?

please look on http://www.mail-archive.com/pgsql-hackers(at)postgresql(dot)org/msg151475.html

I am not alone in opinion so current string to array functions has
not good design

Regards

Pavel

>>
>>> 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
>>
>