2010/7/23 Dimitri Fontaine <dfonta...@hi-media.com>: > Robert Haas <robertmh...@gmail.com> writes: >>>>> so my preferences: >>>>> >>>>> 1. split, join - I checked - we are able to create "join" function >>>>> 2. split, array_join - when only "join" can be a problem >>>>> 3. string_split, array_join - there are not clean symmetry, but it >>>>> respect wide used a semantics - string.split, array.join >>>>> 4. explode, implode >>>>> 5. array_explode, array_implode >>>>> -- I cannot to like array_split - it is contradiction for me. >> >> Yeah, I'd like some more votes, too. > > I still don't see a compelling reason not to extend existing functions > with a third argument. Or are we talking about deprecating them in the > future (like remove their mention in the docs) and have the new names to > replace them, with the new behavior as the default and the extended call > convention as the old behavior?
just incomplete default behave :(. We can enhance old functions, but we cannot to change default behave - it is mean, so we will to ignore a NULLs in arrays forever - but it isn't true a three years. It is a feature now. Please look to archive. There was a discus about it. > > I'm not sure about that, so I think extending existing function is ok. > > Or we would have to have the new functions work well with other types > too, so that it's compelling to move from the old ones. I would not to replace or enhance a to_char function. I plan to use a "implode", "explode" names Regards Pavel Stehule > > Regards, > -- > dim > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
