2010/8/12 Dimitri Fontaine :
>> 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
> 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.
> 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 state
On 11 August 2010 21:52, Tom Lane wrote:
> Peter Geoghegan 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 by more array
convenience functions, i
On Wed, Aug 11, 2010 at 4:21 PM, Peter Geoghegan
wrote:
> On 11 August 2010 18:53, Robert Haas 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
Peter Geoghegan 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.
regards, tom lane
--
Sent
On 11 August 2010 18:53, Robert Haas 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 null
>
> or ju
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:
http://www.postgresql.org/docs/current/stat
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 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 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: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 PL/
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 part
On Wed, Aug 11, 2010 at 1:32 PM, Peter Geoghegan
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
>> use COALESCE() to get
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 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
> 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 Wed, Aug 11, 2010 at 12:36 PM, Tom Lane wrote:
> "David E. Wheeler" 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 anyb
"David E. Wheeler" 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?
> % perl -E '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
On Wed, Aug 11, 2010 at 10:32 AM, Tom Lane wrote:
> Greg Stark 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_
Greg Stark 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 though.
I had fo
Greg Stark 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 general-purpose s
2010/8/11 Greg Stark :
> On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
> wrote:
>> On 10 August 2010 19:48, David E. Wheeler 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
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 pgsql-hacker
On Wed, Aug 11, 2010 at 12:37 AM, Peter Geoghegan
wrote:
> On 10 August 2010 19:48, David E. Wheeler 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
On 10 August 2010 19:48, David E. Wheeler 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 empty
array. So
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:
http://www.post
On 10 August 2010 19:41, Tom Lane 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 patch fails to
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 than
30 matches
Mail list logo
