Re: patch: to_string, to_array functions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: patch: to_string, to_array functions
Дата
Msg-id AANLkTim2NESA07ptiSvK3xecn+4qMNJkd0KBp6O+1FCT@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: to_string, to_array functions  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: patch: to_string, to_array functions  (Pavel Stehule <pavel.stehule@gmail.com>)
Список pgsql-hackers
On Wed, Jul 21, 2010 at 1:48 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> 2010/7/21 Robert Haas <robertmhaas@gmail.com>:
>> On Wed, Jul 21, 2010 at 12:08 PM, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>>>>> I am thinking so we have to do decision about string_to_array and
>>>>> array_to_string deprecation first. If these function will be
>>>>> deprecated, then we can use a similar names (and probably we should to
>>>>> use a similar names) - so text_to_array or array_to_string can be
>>>>> acceptable. If not, then this discus is needless - then to_string and
>>>>> to_array have to be maximally in contrib - stringfunc is good idea -
>>>>> and maybe we don't need thinking about new names.
>>>>
>>>> Well, -1 from me for deprecating string_to_array and array_to_string.
>>>>
>>>> I am not in favor of the names to_string and to_array even if we put
>>>> them in contrib, though.  The problem with string_to_array and
>>>> array_to_string is that they aren't descriptive enough, and
>>>> to_string/to_array is even less so.
>>>
>>> I am not a English native speaker, so I have a different feeling.
>>> These functions do array_serialisation and array_deseralisation, but
>>> this names are too long. I have not idea about better names - it is
>>> descriptive well (for me) text->array, array->text - and these names
>>> shows very cleanly symmetry between functions. I have to repeat - it
>>> is very clean for not native speaker.
>>
>> Well, the problem is that array_to_string(), for example, tells you
>> that an array is being converted to a string, but not how.  And
>> to_string() tells you that you're getting a string, but it doesn't
>> tell you either what you're getting it from or how you're getting it.
>> We already have a function to_char() which can be used to format a
>> whole bunch of different types as strings; I can't see adding a new
>> function with almost the same name that does something completely
>> different.
>>
>> array_split() and array_join(), following Perl?  array_implode() and
>> array_explode(), along the lines suggested by Brendan?
>
> I have a problem with array_split - because there string is split. I
> looked on net - and languages usually uses a "split" or "join". split
> is method of str class in Java. So when I am following Perl, I feel
> better with  just only "split" and "join", but "join" is keyword :( -
> step back, maybe string_split X array_join ?
>
> select string_split('1,2,3,4',',');
> select array_join(array[1,2,3,4],',');
>
> 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.

Well, I guess I prefer my suggestion to any of those (I know... what a
surprise), but I think I could live with #3, #4, or #5.  It's hard for
me to imagine that we really want to create a function called just
join(), given the other meanings that JOIN already has in SQL.

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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: patch: to_string, to_array functions
Следующее
От: Robert Haas
Дата:
Сообщение: Re: multibyte charater set in levenshtein function