On Wed, Aug 11, 2010 at 12:36 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> "David E. Wheeler" <da...@kineticode.com> writes:
>> On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
>>> So maybe we need to revisit the issue. Pavel was claiming that
>>> switching to a zero-element array result was a no-brainer, but evidently
>>> it isn't so. Is anybody still excited about the alternatives?
>
>> % perl -E 'say q{"}, join(",", ""), q{"}'
>> ""
>> % ruby -e 'puts %q{"} + [""].join(",") + %q{"}'
>> ""
>> % python -c 'print "\"" + ",".join([""]) + "\""'
>> ""
>
>> I believe those are all "", rather than '"' + undef + '"'.
>
> If you believe my previous opinion that the design center for these
> functions is arrays of numbers, then a zero-entry text[] array is what
> you want, because you can successfully cast it to a zero-entry array of
> integers or floats or whatever. Returning a single empty string will
> make those cases fail. So at the moment I'm on the side of the fence
> that says zero-entry array is the best answer.
Yeah, I think David's examples are talking about the behavior of join,
but we're trying to decide what split should do. I think the main
argument for making it return NULL is that you can then fairly easily
use COALESCE() to get whatever you want. That's a bit more difficult
if you use return any other value. But I think your argument that an
empty array is better than a one-element array containing an empty
string is very much correct, as between those options.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
