Re: patch: to_string, to_array functions
От | Pavel Stehule |
---|---|
Тема | Re: patch: to_string, to_array functions |
Дата | |
Msg-id | AANLkTinS1PV-w2-JkchxFo4apXI8Sn8--8syBl4JPozT@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: patch: to_string, to_array functions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: patch: to_string, to_array functions
(Robert Haas <robertmhaas@gmail.com>)
|
Список | pgsql-hackers |
2010/7/21 Robert Haas <robertmhaas@gmail.com>: > 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. it hasn't any relation to SQL language - but I don't expect so some like this can be accepted by Tom :). So for this moment we are in agreement on #3, #4, #5. I think, we can wait one or two days for opinions of others - and than I'll fix patch. ok? Regards Pavel > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company >
В списке pgsql-hackers по дате отправления: