Re: patch: to_string, to_array functions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: patch: to_string, to_array functions
Дата
Msg-id AANLkTim2Tg8mWsUnDCoiz_bVEiJ16t+0v=kwB-52maEO@mail.gmail.com
обсуждение исходный текст
Ответ на Re: patch: to_string, to_array functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: patch: to_string, to_array functions  ("David E. Wheeler" <david@kineticode.com>)
Список pgsql-hackers
On Mon, Aug 9, 2010 at 4:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Brendan Jurd <direvus@gmail.com> writes:
>>> I have attached v4 of the patch against HEAD, and also an incremental
>>> patch showing just my changes against v3.
>>>
>>> I'll mark this as ready for committer.
>
> Looking at this, I want to question the implode/explode naming.  I think
> those names are too cute by half, not particularly mnemonic, not visibly
> related to the similar existing functions, and not friendly to any
> future extension in the same area.
>
> My first thought is that we should go back to the string_to_array and
> array_to_string names.  The key reason not to use those names was the
> conflict with the old functions if you didn't specify a third argument,
> but where is the advantage of not specifying the third argument?  It
> would be a lot simpler for people to understand if we just said "the
> two-argument forms work like this, while the three-argument forms work
> like that".  This is especially reasonable because the difference in
> behavior is about nulls in the array, which is exactly what the third
> argument exists to specify.
>
> [ Sorry for not complaining about this before, but I was on vacation
> when the previous naming discussion went on. ]

I can live with that, as long as it's clearly explained in the docs.

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


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: dynamically allocating chunks from shared memory
Следующее
От: Tom Lane
Дата:
Сообщение: Re: dynamically allocating chunks from shared memory