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

Re: string_to_array with empty input

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steve Crawford <scrawford(at)pinpointresearch(dot)com>
Cc: pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: string_to_array with empty input
Date: 2009-03-31 03:26:10
Message-ID: 29554.1238469970@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
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

In response to

Responses

pgsql-hackers by date

Next:From: Stuart BishopDate: 2009-03-31 03:35:38
Subject: Re: pgstattuple triggered checkpoint failure and database outage?
Previous:From: Tom LaneDate: 2009-03-31 03:04:00
Subject: Re: can't load plpython

pgsql-general by date

Next:From: JustinDate: 2009-03-31 03:27:16
Subject: Re: PL/PGSQL arithmetic errors
Previous:From: Tom LaneDate: 2009-03-31 03:12:04
Subject: Re: running two servers on one machine

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