Re: [GENERAL] 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: [GENERAL] string_to_array with empty input
- Date: Mon, 30 Mar 2009 23:26:10 -0400
- Message-id: <29554.1238469970@sss.pgh.pa.us> <text/plain>
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
Home |
Main Index |
Thread Index