From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Steve Crawford <scrawford(at)pinpointresearch(dot)com>, David Fetter <david(at)fetter(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: array_to_string bug? |
Date: | 2009-11-12 18:46:42 |
Message-ID: | 14471.1258051602@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Nov 12, 2009 at 1:28 PM, Steve Crawford
> <scrawford(at)pinpointresearch(dot)com> wrote:
>> Although it might cause a fair amount of backward-compatibility trouble, the
>> string representation could either use NULL to represent a null element as
>> is allowed in other contexts or require that empty-string elements be
>> represented as "" to differentiate ,"", (empty-string element) from ,, (null
>> element).
> That would cause a substantial amount of grief to people who might not
> want that behavior, though. I use these functions for creating
> human-readable output, not for serialization. Simple, predictable
> behavior is very important.
I agree --- we don't want to start introducing quoting rules into
array_to_string. I think the viable alternatives are the current
behavior, or treating a NULL element as if it were an empty string.
David's idea that the entire output should go to NULL might be sane
from a strict semantics point of view, but it also seems to make the
function just about entirely useless in practice.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2009-11-12 18:46:47 | Re: array_to_string bug? |
Previous Message | Jeff Davis | 2009-11-12 18:45:58 | Re: next CommitFest |