Re: [GENERAL] string_to_array with empty input - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [GENERAL] string_to_array with empty input
Date
Msg-id 29554.1238469970@sss.pgh.pa.us
Whole thread Raw
Responses Re: [GENERAL] string_to_array with empty input  ("David E. Wheeler" <david@kineticode.com>)
Re: [GENERAL] string_to_array with empty input  (Greg Stark <greg.stark@enterprisedb.com>)
Re: [GENERAL] string_to_array with empty input  (Brendan Jurd <direvus@gmail.com>)
List pgsql-hackers
Steve Crawford <scrawford@pinpointresearch.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: can't load plpython
Next
From: Alvaro Herrera
Date:
Subject: Re: can't load plpython