| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | "David E(dot) Wheeler" <david(at)kineticode(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 18:18:31 |
| Message-ID: | 13355.1238696311@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Right at the moment, if we stick with the historical definition
>> of the function, *both* camps have to write out their choice of
>> the above. Seems like this is the worst of all possible worlds.
>> We should probably pick one or the other.
> ISTM there are three camps.
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning. AFAICS we can either say that every application
is going to have to put in a CASE wrapper around this function, or say
that we'll make it do the right thing for some of them and the rest have
to put the same wrapper around it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sam Mason | 2009-04-02 18:24:16 | Re: [HACKERS] string_to_array with empty input |
| Previous Message | Robert Haas | 2009-04-02 18:10:01 | Re: [HACKERS] string_to_array with empty input |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-04-02 18:19:46 | Re: [HACKERS] Mentors needed urgently for SoC & PostgreSQL Student Internships |
| Previous Message | Teodor Sigaev | 2009-04-02 18:12:26 | Re: Crash in gist insertion on pathological box data |