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 e
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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgr
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 st
Because your vacation responder is even more broken than that. It
sends the mail to the *From* header address instead of the envelope
from. Aside from not handling mailing lists sanely that also makes it
susceptible to mail loops.
--
Greg
On 3 Apr 2009, at 04:40, Zeugswetter Andreas OSB s
> Could the list admin please unsubscribe Andreas Zeugswetter from the
> lists until he can fix his vacation-responder-gone-nuts?
I am very sorry, fixed. I forgot to set nomail before setting the out of office
assistant
which my company requires me to do in this braindead way.
But I assume Exch
On Thu, Apr 2, 2009 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane 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
>> t
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 ofte
Robert Haas writes:
> On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane 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.
We would only be breaking them if
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane 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
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,
Robert Haas writes:
> On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane 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 pic
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane 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 other.
ISTM t
"David E. Wheeler" 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
> string_to_array('',
On Thu, Apr 2, 2009 at 12:10 PM, David E. Wheeler 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 there's
On Thu, Apr 2, 2009 at 12:17 PM, David E. Wheeler 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 for empty st
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 le
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.
It'
>> I'm speaking primarily of functions as first-class objects, though
>> closures would be nice too. But consider an operation like
>>
>> UPDATE rel SET col1 = MAP ( f OVER col2 )
>>
>> We need to be able to determine whether this is well-typed, just as we
>> do now for any other SQL query. Spec
Robert Haas wrote:
On Wed, Apr 1, 2009 at 3:49 PM, Sam Mason wrote:
On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler wrote:
Well, I'd just point out that the return value of string_to_array() is
text[]. Thus, this is not a problem
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
closer
On Wed, Apr 1, 2009 at 5:22 PM, Tom Lane 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
--
Sent via pgsq
On Wed, Apr 1, 2009 at 3:49 PM, Sam Mason wrote:
> On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
>> On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler
>> wrote:
>> > Well, I'd just point out that the return value of string_to_array() is
>> > text[]. Thus, this is not a problem with
Robert Haas 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 have the empty st
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
...@samason.me.uk;
> pgsql-gene...@postgresql.org; pgsql-hackers@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
>
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-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
On Wed, Apr 01, 2009 at 03:19:23PM -0400, Robert Haas wrote:
> On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler
> 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[
On Wed, Apr 1, 2009 at 1:05 PM, justin 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 with
> in limited cases
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler 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
> this case to ma
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
On Wed, Apr 1, 2009 at 6:23 PM, David E. Wheeler wrote:
> Right, it's making a special case of '', which does seem rather inconsistent
> to me.
"David E. Wheeler" writes:
> On Apr 1, 2009, at 10:05 AM, justin wrote:
>
>> string_to_array('',',')::INT[] works as proposed
>>
>> But
>> string_to_
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
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 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. B
"David E. Wheeler" 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 meant to be useful
Tom Lane wrote:
Robert Haas writes:
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
string_to_array('',',')::INT[] => invalid input syntax for integer: ""
Oof. That
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
sing
Robert Haas writes:
> On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
>> On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason 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 anyth
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
> On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason 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 anything else
that's been offer
[ oops, forgot to send this to -hackers before ]
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 s
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 t
On Tue, Mar 31, 2009 at 6:44 PM, justin 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 building a
parser an
Greg Stark wrote:
On Tue, Mar 31, 2009 at 5:48 PM, justin 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 an
On Tue, Mar 31, 2009 at 5:48 PM, justin 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 string_to_array('
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
N
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 "arr
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 count_elements(stri
Greg Stark wrote:
> On Tue, Mar 31, 2009 at 4:17 PM, Alvaro Herrera
> wrote:
> > Greg Stark wrote:
> >> Could the list admin please unsu*scribe Andreas Zeugswetter from the
> >> lists until he can fix his vacation-responder-gone-nuts?
> >
> > I've set him "nomail" on pgsql-hackers.
>
> Thanks. Is
On Tue, Mar 31, 2009 at 4:17 PM, Alvaro Herrera
wrote:
> Greg Stark wrote:
>> Could the list admin please unsubscribe Andreas Zeugswetter from the
>> lists until he can fix his vacation-responder-gone-nuts?
>
> I've set him "nomail" on pgsql-hackers.
Thanks. Is there a better address to reach lis
Greg Stark writes:
> On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason 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?
regards, tom lane
--
Sent v
On Tue, Mar 31, 2009 at 03:43:37PM +0100, Greg Stark wrote:
> On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd 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 eleme
gt; Date: Tue, Mar 31, 2009 at 3:44 PM
> Subject: Abwesend: [HACKERS] [GENERAL] string_to_array with empty input
> To: Greg Stark
>
>
> Automatic reply: I will not be reading mail until 1.4.2009. For urgent
> matters please contact my colleagues.
>
> Gree
Could the list admin please unsubscribe Andreas Zeugswetter from the
lists until he can fix his vacation-responder-gone-nuts?
-- Forwarded message --
From: Zeugswetter Andreas OSB sIT
Date: Tue, Mar 31, 2009 at 3:44 PM
Subject: Abwesend: [HACKERS] [GENERAL] string_to_array with
On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
>
> string_to_array('',',')::INT[] => invalid input syntax for integer: ""
Oof. That's a good point.
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.o
On Tue, Mar 31, 2009 at 7:45 AM, Brendan Jurd 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.
>
> However, I no
On Tue, Mar 31, 2009 at 05:45:33PM +1100, Brendan Jurd wrote:
> On Tue, Mar 31, 2009 at 2: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
On Tue, Mar 31, 2009 at 2: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.)
>
My fi
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 string_t
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 seems
Steve Crawford 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 el
60 matches
Mail list logo
