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
29 matches
Mail list logo
