Re: patch: to_string, to_array functions - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: patch: to_string, to_array functions
Date
Msg-id AANLkTikSEsxi=4fxFnco1iciMiocFfOCF12pXreKUMup@mail.gmail.com
Whole thread Raw
In response to Re: patch: to_string, to_array functions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: patch: to_string, to_array functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.

Is there any reason why array functions need the type prefix when
other type conversion functions don't?  Why didn't we name unnest()
array_unnest()?

merlin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: dynamically allocating chunks from shared memory
Next
From: Hector Beyers
Date:
Subject: Hector Beyers wants to stay in touch on LinkedIn