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
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
