From: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, justin <justin(at)emproshunts(dot)com>, Greg Stark <stark(at)enterprisedb(dot)com>, Sam Mason <sam(at)samason(dot)me(dot)uk>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] string_to_array with empty input |
Date: | 2009-04-02 16:17:21 |
Message-ID: | A92B4688-A246-41A5-91A4-033EA5FA2B7C@kineticode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
> Another way to state the point is that we can offer people a choice of
> two limitations: string_to_array doesn't work for zero-length lists,
> or string_to_array doesn't work for empty strings (except most of the
> time, it does). The former is sounding less likely to bite people
> unexpectedly.
Right, very well put.
> Or we could stick to the current behavior and say "use COALESCE() to
> resolve the ambiguity, if you need to".
Steve has a point that leaving it as-is leaves it as impossible to
tell the difference between string_to_array(NULL, ',') and
string_to_array('', ','). The former properly handles an unknown
value, while the latter, where '' is a known value, seems weird to be
returning NULL.
Best,
David
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Mason | 2009-04-02 16:27:55 | Re: reducing IO and memory usage: sending the content of a table to multiple files |
Previous Message | David E. Wheeler | 2009-04-02 16:10:34 | Re: [HACKERS] string_to_array with empty input |
From | Date | Subject | |
---|---|---|---|
Next Message | Werner Echezuria | 2009-04-02 16:21:34 | Re: Sort a column that does not exist |
Previous Message | David E. Wheeler | 2009-04-02 16:10:34 | Re: [HACKERS] string_to_array with empty input |