Re: patch: to_string, to_array functions

On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/7/21 Pavel Stehule <pavel.stehule@gmail.com>:
>> 2010/7/21 Robert Haas <robertmhaas@gmail.com>:
>>> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>> 2010/7/21 Robert Haas <robertmhaas@gmail.com>:
>>>>> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro
>>>>> <itagaki.takahiro@gmail.com> wrote:
>>>>>> 2010/7/20 Pavel Stehule <pavel.stehule@gmail.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@postgresql.org/msg151475.html
>
> I am not alone  in opinion so current string to array functions has
> not good design

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().

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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company