On Wed, Jul 21, 2010 at 8:14 AM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > 2010/7/21 Pavel Stehule <pavel.steh...@gmail.com>: >> 2010/7/21 Robert Haas <robertmh...@gmail.com>: >>> On Wed, Jul 21, 2010 at 7:39 AM, Pavel Stehule <pavel.steh...@gmail.com> >>> wrote: >>>> 2010/7/21 Robert Haas <robertmh...@gmail.com>: >>>>> On Wed, Jul 21, 2010 at 12:39 AM, Itagaki Takahiro >>>>> <itagaki.takah...@gmail.com> wrote: >>>>>> 2010/7/20 Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
