On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:

+1.  I find this argument much more compelling than anything else
that's been offered up so far.

Yeah. It seems to me that if you consider only the case where the array elements are text, there's a weak preference for considering '' to be a single empty string; but as soon as you think about any other datatype,
there's a strong preference to consider it a zero-element list.  So I
too have come around to favor the latter interpretation.  Do we have
any remaining holdouts?

Well, I'd just point out that the return value of string_to_array() is text[]. Thus, this is not a problem with string_to_array(), but a casting problem from text[] to int[]. Making string_to_array() return a NULL for this case to make casting simpler is addressing the problem in the wrong place, IMHO. If I want to do this in Perl, for example, I'd do something like this:

my @ints = grep { defined $_ && $_ ne '' } split ',', $string;

So I split the string into an array, and then remove unreasonable values. This also allows me to set defaults:

my @ints = map { $_ || 0 } split ',', $string;

This ensures that I get the proper number of records in the example of something like '1,2,,4'.

So I still think that string_to_array('', ',') should return '{""}', and how casting is handled should be left to the user to flexibly handle.

That said, I'm not seeing a simple function for modifying an array. I'd have to write one for each specific case. :-(

Best,

David




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to