Did I miss the exciting conclusion or did this drift silently off radar?
I seem to recall three options:
1. Leave as is. Arguments: least effort, no backward compatibility
issues, since array_to_string evaluate both an array with single empty
string and an array with no elements to an empty
Steve Crawford wrote:
Did I miss the exciting conclusion or did this drift silently off radar?
it was pretty well split between the options. tabled for another time.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Apr 7, 2009, at 8:07 AM, Steve Crawford wrote:
In scenario 2, there were two options:
2a. Return zero-element array.
2b. Return array with single empty-string element.
My impression was that among the change options, 2b had the most
support (it is the most useful for the use-cases I've
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example
of something like '1,2,,4'.
I can't see that there's any way to do this in SQL regardless of how
we define this operation.
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does). The former is sounding
Leif B. Kristensen wrote:
On Thursday 2. April 2009, Steve Crawford wrote:
Currently string_to_array(null, ',') yields a null result -
indistinguishable from string_to_array('',','). Wrapping in coalesce
does not help distinguish true null input from empty-string input. I'm
not sure at the
On Thu, Apr 02, 2009 at 09:29:04AM -0700, Steve Crawford wrote:
Leif B. Kristensen wrote:
Somehow this reminds me of the old division by zero problem.
IMO, the proper way to handle this kind of anomaly would be to test if
the length of the string is non-zero before submitting it to the
On Thu, Apr 2, 2009 at 12:17 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work
On Thu, Apr 2, 2009 at 12:10 PM, David E. Wheeler da...@kineticode.com wrote:
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example of
something like '1,2,,4'.
I can't see that
David E. Wheeler da...@kineticode.com writes:
Or we could stick to the current behavior and say use COALESCE() to
resolve the ambiguity, if you need to.
Steve has a point that leaving it as-is leaves it as impossible to
tell the difference between string_to_array(NULL, ',') and
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their choice of
the above. Seems like this is the worst of all possible worlds.
We should probably pick one or the
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their choice of
the above. Seems like this is the worst of all possible
On Thu, Apr 02, 2009 at 02:04:41PM -0400, Tom Lane wrote:
A correct fix
outside-the-function would look more like
case when str = '' then '{}'::text[] else string_to_array(str, ',') end
which should correctly yield NULL for NULL input and an empty array
for empty input. Similarly, if
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Right at the moment, if we stick with the historical definition
of the function, *both* camps have to write out their
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning.
So that we don't break existing apps because of an issue that is
trivial to work around.
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the right thing more often
On Thu, Apr 2, 2009 at 2:50 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
If there's a camp that actually *wants* a NULL result for this case,
I missed the reasoning.
So that we don't break
On Thu, Apr 02, 2009 at 12:06:01PM -0700, David E. Wheeler wrote:
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely arbitrary choice one way or the other but the current
behaviour is certainly wrong.
I'd go with returning
On Tue, Mar 31, 2009 at 05:08:45PM +0100, Greg Stark wrote:
Both interpretations are clearly consistent but it depends on whether
you think it's a bunch of text strings concatenated together or if
it's a list of objects.
The example of string_to_array('',',')::int[] is relevant to this
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark st...@enterprisedb.com wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Oof. That's a good point.
+1. I find this argument much more compelling than
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark st...@enterprisedb.com wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Oof. That's a good point.
+1. I
On Apr 1, 2009, at 9:02 AM, Tom Lane wrote:
+1. I find this argument much more compelling than anything else
that's been offered up so far.
Yeah. It seems to me that if you consider only the case where the
array
elements are text, there's a weak preference for considering '' to
be a
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark st...@enterprisedb.com wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid
David E. Wheeler da...@kineticode.com writes:
Well, I'd just point out that the return value of string_to_array() is
text[].
True...
Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is
On Apr 1, 2009, at 10:09 AM, Tom Lane wrote:
Thus, this is not a problem with string_to_array(), but a
casting problem from text[] to int[].
Nonsense. The question is whether string_to_array is meant to be
useful
for lists of anything except text. I agree you could argue that it
isn't.
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the difference between a empty string to a
string with many blank entries
On Wed, Apr 01, 2009 at 10:23:18AM -0700, David E. Wheeler wrote:
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as proposed
But
string_to_array(',,,', ',' )::INT[] Fails
or
string_to_array('1,2,,4', ',' )::INT[] Fails .
I'm trying to understand the
On Wed, Apr 1, 2009 at 6:23 PM, David E. Wheeler da...@kineticode.com wrote:
Right, it's making a special case of '', which does seem rather inconsistent
to me.
David E. Wheeler da...@kineticode.com writes:
On Apr 1, 2009, at 10:05 AM, justin wrote:
string_to_array('',',')::INT[] works as
On Wed, Apr 01, 2009 at 07:40:16PM +0100, Greg Stark wrote:
The existing behaviour of returning NULL is the only consistent
choice since the correct value is unknown. And one could argue that
it's easier to replace NULL with the correct value if the programmer
knows using coalesce than it is
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler da...@kineticode.com wrote:
Well, I'd just point out that the return value of string_to_array() is
text[]. Thus, this is not a problem with string_to_array(), but a casting
problem from text[] to int[]. Making string_to_array() return a NULL for
On Wed, Apr 1, 2009 at 1:05 PM, justin jus...@emproshunts.com wrote:
I'm still a hold out, We are taking a string putting it into a array based
on a delimiter. That is very simple and straight forward. Yet many argue
if we want to cast this into another data type the function should deal
If someone can show me a real world example this logic simplifies the
code and has more uses I'll bite
I just presently can't see how this works better.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
@postgresql.org; pgsql-hack...@postgresql.org
Subject: Re: [HACKERS] [GENERAL] string_to_array with empty input
If someone can show me a real world example this logic simplifies the
code and has more uses I'll bite
I just presently can't see how this works better.
--
Sent via pgsql
Martin Gainty wrote:
Split strings into array elements using provided
delimiter
string_to_array('xx~^~yy~^~zz', '~^~')
output: {xx,yy,zz}
http://www.postgresql.org/docs/8.3/interactive/functions-array.html
Sorry thats not the question i'm asking.
We are debating if it makes
Robert Haas robertmh...@gmail.com writes:
If you take 0 items of any type whatsoever and join them together with
commas, you will get the empty string. It is also true that if you
join 1 item together with commas, you will get that item back, and if
that item is the empty string, you will now
On Wed, Apr 1, 2009 at 5:22 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Or we could stick to the current behavior and say use COALESCE() to
resolve the ambiguity, if you need to.
If there's no consensus on changing the behavior, it's probably better
to be backward compatible than not.
...Robert
--
Tom Lane wrote:
I'm starting to vacillate again. It's clear that for the purposes
of string_to_array, an empty input string is fundamentally ambiguous:
it could mean a list of no things, or a list of one empty thing.
Agreed. Of the two, a list of one empty thing makes string_to_array
On Thursday 2. April 2009, Steve Crawford wrote:
Currently string_to_array(null, ',') yields a null result -
indistinguishable from string_to_array('',','). Wrapping in coalesce
does not help distinguish true null input from empty-string input. I'm
not sure at the moment what other cases exist
Sorry for top-posting--blame apple.
Hm my first instinct was indeed to make it a zero-length array. I was
thinking of the input as a list and surely there are no elements in
a list which empty. I had to think a while until a length-1 array made
sense.
I suppose the thinking was
On Tue, Mar 31, 2009 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Tue, Mar 31, 2009 at 05:45:33PM +1100, Brendan Jurd wrote:
On Tue, Mar 31, 2009 at 2:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
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
On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd dire...@gmail.com wrote:
My first thought was that it should be a zero-element array, because
then the string_to_array() behaviour would conform to the notion that
it returns an array with 1 element per string fragment bounded by the
delimiter.
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Oof. That's a good point.
--
greg
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
On Tue, Mar 31, 2009 at 03:43:37PM +0100, Greg Stark wrote:
On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd dire...@gmail.com wrote:
My first thought was that it should be a zero-element array, because
then the string_to_array() behaviour would conform to the notion that
it returns an array
Greg Stark st...@enterprisedb.com writes:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason s...@samason.me.uk wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Oof. That's a good point.
Isn't that an argument in favor of the zero-size-array definition?
On Mar 31, 2009, at 8:34 AM, Sam Mason wrote:
What do you really expect to be returned for things like
select count_elements(string_to_array('butter,tea,milk',','))
3 = {butter,tea,milk}
select count_elements(string_to_array('butter,tea',','))
2 = {butter,tea}
select
On Tue, Mar 31, 2009 at 4:34 PM, Sam Mason s...@samason.me.uk wrote:
That's also a disingenuous example; what would you expect back from:
select count_elements(string_to_array('butter,,milk',','))
I think the semantics you want is what you'd get from:
Sam Mason wrote:
I'd expect 3,2,1 and 1.
That's also a disingenuous example; what would you expect back from:
select count_elements(string_to_array('butter,,milk',','))
I think the semantics you want is what you'd get from:
array_filter_blanks(string_to_array($1,$2))
where I defined
Sam Mason wrote:
string_to_array('',',')::INT[] = invalid input syntax for integer:
Which you don't get at the moment; although you do currently get it in
other common cases such as:
string_to_array('1,',',')::INT[]
If you want backwards compatible behaviour you could always bung a
On Tue, Mar 31, 2009 at 5:48 PM, justin jus...@emproshunts.com wrote:
But consider this fails also
select string_to_array('1, , 3', ',' )::int[] = ERROR: invalid input
syntax for integer:
yet this works
select string_to_array('1, 2, 3',',')::int[]
Sure, and the analogous pair
Greg Stark wrote:
On Tue, Mar 31, 2009 at 5:48 PM, justin jus...@emproshunts.com wrote:
But consider this fails also
select string_to_array('1, , 3', ',' )::int[] = ERROR: invalid input
syntax for integer: " "
yet this works
select string_to_array('1, 2, 3',',')::int[]
On Tue, Mar 31, 2009 at 6:44 PM, justin jus...@emproshunts.com wrote:
Consider this. I have intelligent part numbers that need to be split apart
to simplify searching and do math with.
string_to_array(' F-2500-50 ', '-' ) ::int[]
Yeah, that's what I've said about three times. If you're
This thread being cross posted has made it a bit
confusing
Greg Stark wrote:
Nobody has ever suggested filtering out empty elements or dealing
specially with spaces or anything else like that. If you're talking
about that then you've missed the original question.
"Does anyone want
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
Steve Crawford scrawf...@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
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
On Mar 30, 2009, at 8:26 PM, Tom Lane wrote:
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.)
Hrm. There
57 matches
Mail list logo
