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 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@postgresql.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 >> > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
