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