Skip site navigation (1) Skip section navigation (2)

Re: string_to_array with empty input

From: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Steve Crawford <scrawford(at)pinpointresearch(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: string_to_array with empty input
Date: 2009-03-31 06:16:05
Message-ID: F000AEA8-630C-40A6-A83D-AEA291A03B79@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
Sorry for top-posting--blame apple.

Hm my first instinct was indeed to make it a zero-length array. I was  
thinking of the input as a "list" and surely there are no elements in  
a list which empty. I had to think a while until a length-1 array made  
sense.

I suppose the thinking was string_to_array is the inverse of an  
array_to_string operation then there are multiple possible answers.  
You might have joined a zero length or a singleton array of an empty  
string....
and since it's unknown which was the original value null is the right  
answer...

I agree that picking an arbitrary choice is going to be more useful in  
practice though.

-- 
Greg


On 30 Mar 2009, at 23:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Steve Crawford <scrawford(at)pinpointresearch(dot)com> writes:
>> I have a query that converts a string to an array with the
>> string_to_array function. Sometimes the input is an empty string  
>> (not a
>> null, but a string of zero-length). I had expected the result to be a
>> one-element array with an empty string as the first and only  
>> element but
>> instead it returned null. I looked at the docs and didn't find the
>> observed behavior documented.
>
> The behavior is pretty intentional according to the source code:
>
>    /* return NULL for empty input string */
>    if (inputstring_len < 1)
>    {
>        text_position_cleanup(&state);
>        PG_RETURN_NULL();
>    }
>
> I agree this seems less than consistent though, especially seeing
> that you *don't* get a null for a zero-length separator, which if
> anything is a more poorly defined case.
>
> I doubt it'd be a good idea to back-patch a change for this,
> but I could see altering the definition for 8.4.
>
> Does anyone want to argue for keeping it the same?  Or perhaps
> argue that a zero-element array is a more sensible result than
> a one-element array with one empty string?  (It doesn't seem
> like it to me, but maybe somebody thinks so.)
>
>            regards, tom lane
>
> -- 
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

In response to

pgsql-hackers by date

Next:From: Brendan JurdDate: 2009-03-31 06:45:33
Subject: Re: [HACKERS] string_to_array with empty input
Previous:From: Heikki LinnakangasDate: 2009-03-31 05:19:57
Subject: Re: 8.3.5: Crash in CountActiveBackends() - lockless race?

pgsql-general by date

Next:From: Brendan JurdDate: 2009-03-31 06:45:33
Subject: Re: [HACKERS] string_to_array with empty input
Previous:From: Stuart BishopDate: 2009-03-31 04:29:21
Subject: Re: [GENERAL] pgstattuple triggered checkpoint failure and database outage?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group