Really?
FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
I mean, doing everything is sort of clunky in PL/pgsql, but this
doesn't seem particularly bad as PL/pgsql idioms go.
this simple construction can take much more memory than other. I
proposed two or three years ago FOREACH statement
I definitely agree that PL/pgsql could be more usable. Or if not,
then some other PL with a better overall design could be more usable.
I am not entirely sure how to create such a thing, however.
Would the standard plpsm be just that? Pavel maintains a pg implémentation of
it, I believe.
2010/8/12 Dimitri Fontaine dfonta...@hi-media.com:
I definitely agree that PL/pgsql could be more usable. Or if not,
then some other PL with a better overall design could be more usable.
I am not entirely sure how to create such a thing, however.
Would the standard plpsm be just that? Pavel
On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 10 August 2010 19:48, David E. Wheeler da...@kineticode.com wrote:
On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
I, personally, would expect an empty array output given an empty
input, and a null output
There's already been one rather-long thread on this topic.
http://thread.gmane.org/gmane.comp.db.postgresql.general/121450
In there I argue for the empty array interpretation and Tom goes back
and forth a few times. I'm not sure where that thread ended though.
--
greg
--
Sent via
2010/8/11 Greg Stark gsst...@mit.edu:
On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 10 August 2010 19:48, David E. Wheeler da...@kineticode.com wrote:
On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
I, personally, would expect an empty array output
Greg Stark gsst...@mit.edu writes:
Ideally you really want string_to_array(array_to_string(x, ':'),':')
to return x. There's no safe return value to pick for the cases where
x=[''] and x=[] that will make this work.
It's easy to see that string_to_array/array_to_string are *not* usable
as
Greg Stark gsst...@mit.edu writes:
There's already been one rather-long thread on this topic.
http://thread.gmane.org/gmane.comp.db.postgresql.general/121450
In there I argue for the empty array interpretation and Tom goes back
and forth a few times. I'm not sure where that thread ended
On Wed, Aug 11, 2010 at 10:32 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
Ideally you really want string_to_array(array_to_string(x, ':'),':')
to return x. There's no safe return value to pick for the cases where
x=[''] and x=[] that will make this work.
It's
On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
I had forgotten that discussion. It looks like we trailed off without
any real consensus: there was about equal sentiment for an array with
zero elements and an array with one empty-string element. We ended
up leaving it alone because (a) that
David E. Wheeler da...@kineticode.com writes:
On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
So maybe we need to revisit the issue. Pavel was claiming that
switching to a zero-element array result was a no-brainer, but evidently
it isn't so. Is anybody still excited about the alternatives?
%
On Wed, Aug 11, 2010 at 12:36 PM, Tom Lane t...@sss.pgh.pa.us wrote:
David E. Wheeler da...@kineticode.com writes:
On Aug 11, 2010, at 7:41 AM, Tom Lane wrote:
So maybe we need to revisit the issue. Pavel was claiming that
switching to a zero-element array result was a no-brainer, but
Yeah, I think David's examples are talking about the behavior of join,
but we're trying to decide what split should do. I think the main
argument for making it return NULL is that you can then fairly easily
use COALESCE() to get whatever you want. That's a bit more difficult
if you use
On Aug 11, 2010, at 9:36 AM, Tom Lane wrote:
I believe those are all , rather than '' + undef + ''.
If you believe my previous opinion that the design center for these
functions is arrays of numbers, then a zero-entry text[] array is what
you want, because you can successfully cast it to
On Aug 11, 2010, at 9:40 AM, Robert Haas wrote:
Yeah, I think David's examples are talking about the behavior of join,
but we're trying to decide what split should do.
Right, sorry about that.
I think the main
argument for making it return NULL is that you can then fairly easily
use
On Wed, Aug 11, 2010 at 1:32 PM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
Yeah, I think David's examples are talking about the behavior of join,
but we're trying to decide what split should do. I think the main
argument for making it return NULL is that you can then fairly easily
On Aug 11, 2010, at 10:53 AM, Robert Haas wrote:
Iterating through an array with plpgsql, for example, is more clunky
than it should be.
Really?
FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
I mean, doing everything is sort of clunky in PL/pgsql, but this
doesn't seem particularly
On 08/11/2010 01:54 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 10:53 AM, Robert Haas wrote:
Iterating through an array with plpgsql, for example, is more clunky
than it should be.
Really?
FOR var IN SELECT UNNEST(arr) LOOP ... END LOOP
I mean, doing everything is sort of clunky in
On Aug 11, 2010, at 10:58 AM, Andrew Dunstan wrote:
for i in array_lower(myarray,1) .. array_upper(myarray,1) loop ...
works well
for i in select array_subscripts(myarray, 1) loop ...
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On 08/11/2010 01:59 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 10:58 AM, Andrew Dunstan wrote:
for i in array_lower(myarray,1) .. array_upper(myarray,1) loop ...
works well
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
cheers
andrew
On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
http://www.postgresql.org/docs/current/static/functions-srf.html#FUNCTIONS-SRF-SUBSCRIPTS
On 08/11/2010 02:39 PM, David E. Wheeler wrote:
On Aug 11, 2010, at 11:35 AM, Andrew Dunstan wrote:
for i in select array_subscripts(myarray, 1) loop ...
That's not a built-in function AFAIK.
Pavel pointed out to me only yesterday that it is:
On 11 August 2010 18:53, Robert Haas robertmh...@gmail.com wrote:
I think that there's a need for additional built-in array functions,
including one to succinctly test if an array has no elements.
What do you propose? I think the easiest ways to do it right now are:
array_length(arr, 1) is
Peter Geoghegan peter.geoghega...@gmail.com writes:
What's wrong with something like array_is_empty(anyarray) returns
boolean?
What's that got to do with iterating over an array? We could certainly
provide it if it were commonly useful, but I'm not convinced of that.
On Wed, Aug 11, 2010 at 4:21 PM, Peter Geoghegan
peter.geoghega...@gmail.com wrote:
On 11 August 2010 18:53, Robert Haas robertmh...@gmail.com wrote:
I think that there's a need for additional built-in array functions,
including one to succinctly test if an array has no elements.
What do you
On 11 August 2010 21:52, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Geoghegan peter.geoghega...@gmail.com writes:
What's wrong with something like array_is_empty(anyarray) returns
boolean?
What's that got to do with iterating over an array?
Only that I'm of the opinion that we'd be well served
Looking through Pavel's string_to_array patch, I notice that the new
version of string_to_array returns an empty (zero-element) array when
the input string is of zero length, whereas the traditional version
returned NULL instead. The patch fails to emulate the old behavior
exactly, but rather
On 10 August 2010 19:41, Tom Lane t...@sss.pgh.pa.us wrote:
Looking through Pavel's string_to_array patch, I notice that the new
version of string_to_array returns an empty (zero-element) array when
the input string is of zero length, whereas the traditional version
returned NULL instead. The
On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
I, personally, would expect an empty array output given an empty
input, and a null output for a null input.
+1
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On 10 August 2010 19:48, David E. Wheeler da...@kineticode.com wrote:
On Aug 10, 2010, at 11:46 AM, Thom Brown wrote:
I, personally, would expect an empty array output given an empty
input, and a null output for a null input.
+1
Agreed. After all, the result isn't indeterminate - it's an
30 matches
Mail list logo
