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
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? |
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? |