Re: [HACKERS] string_to_array with empty input

From: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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-07 15:07:56
Message-ID: 49DB6C4C.3070004@pinpointresearch.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Did I miss the exciting conclusion or did this drift silently off radar?

I seem to recall three options:

1. Leave as is. Arguments: least effort, no backward compatibility
issues, since array_to_string evaluate both an array with single empty
string and an array with no elements to an empty string, string_to_array
on empty strings is ambiguous so we'll call it null. But: means that the
result of null input and non-null empty-string both result in null
output, requires everyone to explicitly handle empty strings (with the
side effect that they really know what the result will be) instead of
"helping" the majority of users. Requires: documentation change to
accurately describe function's behavior.

2. Change function to return an array. Arguments: Distinguishes null
from non-null input, easier coding for most cases, perhaps a less
surprising result. But: not backward compatible, requires somewhat
arbitrary decision on correct return value. Requires: code
change/testing, documentation updates.

In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.

My impression was that among the "change" options, 2b had the most
support (it is the most useful for the use-cases I've encountered so it
gets my vote). If the consensus is to change the function, it may be too
late for 8.4. But the documentation could be updated to reflect current
and planned behavior.

Cheers,
Steve

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message justin 2009-04-07 15:13:15 Re: [HACKERS] string_to_array with empty input
Previous Message Tom Lane 2009-04-07 14:26:23 Re: bug in 8.4 pg_dumpall ?

Browse pgsql-hackers by date

  From Date Subject
Next Message justin 2009-04-07 15:13:15 Re: [HACKERS] string_to_array with empty input
Previous Message Tom Lane 2009-04-07 14:53:39 Re: Bug of ALTER TABLE DROP CONSTRAINT