Robert Haas <robertmhaas@gmail.com> writes:
> If you take 0 items of any type whatsoever and join them together with
> commas, you will get the empty string. It is also true that if you
> join 1 item together with commas, you will get that item back, and if
> that item is the empty string, you will now have the empty string. I
> think it's better to worry more about the first case because it
> applies to any type at all, whereas the latter case ONLY applies in
> situations where the empty string is a potentially legal value.
I'm starting to vacillate again. It's clear that for the purposes
of string_to_array, an empty input string is fundamentally ambiguous:
it could mean a list of no things, or a list of one empty thing.
So the two cases in which an application can safely make use of this
function are
(1) if lists of no things never happen.
(2) if lists never contain empty things.
Either rule allows us to resolve the ambiguity. We've been discussing
the fact that (2) is an okay assumption for many non-text data types,
but none-the-less string_to_array is in itself a text function and (2)
is not very good for text. Making this worse, the format *appears*
to work fine for empty strings, so long as you don't have exactly
one of them. So it seems like applications might be much more likely
to violate (2) than (1).
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.
Or we could stick to the current behavior and say "use COALESCE() to
resolve the ambiguity, if you need to".
regards, tom lane
