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

From Pavel Stehule
Subject Re: patch: to_string, to_array functions
Date
Msg-id AANLkTikdvcxfF3u4BLxH+HoWd2BixvYYqYF9Hh7eEc-d@mail.gmail.com
Whole thread Raw
In response to Re: patch: to_string, to_array functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hello

2010/8/9 Tom Lane <tgl@sss.pgh.pa.us>:
> 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.
>

The name isn't important - I believe so you or Robert can choose the
best name. Important is default behave. On an start is idea, so
functions that lost some information isn't optimal - and  it is
array_to_string problem - because this function quietly skip NULL
fields, if there are. So it was a motivation to write these functions.

Regards

Pavel Stehule

> [ Sorry for not complaining about this before, but I was on vacation
> when the previous naming discussion went on. ]
>
>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: SHOW TABLES
Next
From: Simon Riggs
Date:
Subject: Re: SHOW TABLES