Re: string_to_array with empty input

From: Justin <justin(at)emproshunts(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: string_to_array with empty input
Date: 2009-03-31 04:03:08
Message-ID: 49D195FC.6070403@emproshunts.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Tom Lane wrote:
> 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
>

I like the array to contain single zero length string. A string was
passed in although empty, its still a string not a NULL.

Returning an empty array implies nothing was passed to the function
although something was. That seems kinda odd to me also, give back what
was sent in broken into an array.

I use this and split_part allot in our database to break apart part numbers

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-03-31 04:10:55 Re: pgstattuple triggered checkpoint failure and database outage?
Previous Message Stuart Bishop 2009-03-31 03:35:38 Re: pgstattuple triggered checkpoint failure and database outage?

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-03-31 04:10:55 Re: pgstattuple triggered checkpoint failure and database outage?
Previous Message Stuart Bishop 2009-03-31 03:35:38 Re: pgstattuple triggered checkpoint failure and database outage?