2010/7/23 Dimitri Fontaine <dfontaine@hi-media.com>:
> Robert Haas <robertmhaas@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
>