Tom Lane wrote:

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark <stark@enterprisedb.com> wrote:

On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason <sam@samason.me.uk> wrote:

string_to_array('',',')::INT[]  => invalid input syntax for integer: ""

Oof. That's a good point.

+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?

			regards, tom lane

I'm still a hold out, We are taking a string putting it into a array based on a delimiter. That is very simple and straight forward. Yet many argue if we want to cast this into another data type the function should deal with in limited cases.

string_to_array('',',')::INT[] works as proposed

But
string_to_array(',,,', ',' )::INT[]   Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .

I'm trying to understand the difference between a empty string to a string with many blank entries between the delimiter.
Consider   ',,,,,,' = '' once the delimiter is removed . Yet Seven zero length entries were passed. How is that going to be handled????

In one case it works and yet other cases it fails. This is inconsistent behavior. Unless all zero length strings are removed or are treated as NULLs I can't see how casting to another type is going to work.

If zero length strings are treated as NULLs this creates idea that zero length strings are = to NULLs.

The input is a string and the output is text[], casting to another data type is error prone and should be handled by the programmer.