Robert Haas writes:
> On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane wrote:
>> plpgsql's parser is rickety enough that I don't have a lot of confidence
>> in its ability to do things that way.
> Bummer. Rickety is not good.
Agreed, but it's not entirely the parser's fault: the language
definition i
On Fri, Dec 17, 2010 at 2:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
>>> Robert Haas writes:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distin
Robert Haas writes:
> On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> Unfortunately, there are likely to be a limited number of such
>>> keywords available. While I agree it's helpful to have a clear
>>> distinction between what FOR does and what FOREACH does, it's w
On Fri, Dec 17, 2010 at 2:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> Unfortunately, there are likely to be a limited number of such
>> keywords available. While I agree it's helpful to have a clear
>> distinction between what FOR does and what FOREACH does, it's wholly
>> conventional here
2010/12/17 Tom Lane :
> Pavel Stehule writes:
>> Second semi argument for using ARRAY keyword is a verbosity of
>> PL/pgSQL. So from this perspective a ARRAY should be minimally
>> optional and ensure, so expr result will be really a array. But with a
>> optional ARRAY keyword we leaving a simple
Pavel Stehule writes:
> Second semi argument for using ARRAY keyword is a verbosity of
> PL/pgSQL. So from this perspective a ARRAY should be minimally
> optional and ensure, so expr result will be really a array. But with a
> optional ARRAY keyword we leaving a simple enhancing in future (on
> pa
Robert Haas writes:
> Unfortunately, there are likely to be a limited number of such
> keywords available. While I agree it's helpful to have a clear
> distinction between what FOR does and what FOREACH does, it's wholly
> conventional here and won't be obvious without careful reading of the
> do
2010/12/17 Robert Haas :
> On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane wrote:
>> "David E. Wheeler" writes:
>>> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
Well, we did beat up Pavel over trying to shoehorn this facility into
the existing FOR syntax, so I can hardly blame him for thinkin
On 17.12.2010 21:04, Robert Haas wrote:
Unfortunately, there are likely to be a limited number of such
keywords available. While I agree it's helpful to have a clear
distinction between what FOR does and what FOREACH does, it's wholly
conventional here and won't be obvious without careful readin
> We would need an extra keyword if there were some third kind of
> iteration that was fundamentally different from either of these, but
> like I said, I don't see a plausible candidate. So right at the moment,
> I'm leaning to the position that we could do without the ARRAY keyword
> in FOREACH.
On Fri, Dec 17, 2010 at 1:38 PM, Tom Lane wrote:
> "David E. Wheeler" writes:
>> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
>>> Well, we did beat up Pavel over trying to shoehorn this facility into
>>> the existing FOR syntax, so I can hardly blame him for thinking this
>>> way. The question i
"David E. Wheeler" writes:
> On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
>> Well, we did beat up Pavel over trying to shoehorn this facility into
>> the existing FOR syntax, so I can hardly blame him for thinking this
>> way. The question is whether we're willing to assume that FOREACH will
>> b
On Dec 17, 2010, at 9:31 AM, Tom Lane wrote:
> Well, we did beat up Pavel over trying to shoehorn this facility into
> the existing FOR syntax, so I can hardly blame him for thinking this
> way. The question is whether we're willing to assume that FOREACH will
> be limited to iterating over array
2010/12/17 Andrew Dunstan :
>
>
> On 12/17/2010 12:15 PM, Pavel Stehule wrote:
>>
>> 2010/12/17 Itagaki Takahiro:
>>>
>>> It should be not a main subject, but I remember there was a discussion
>>> that "IN ARRAY array-expression" looks redundant for a literal array:
>>>
>>> IN ARRAY ARRAY[1, 3, 5]
Andrew Dunstan writes:
> On 12/17/2010 12:15 PM, Pavel Stehule wrote:
>> The reason for this is bigger space for possible
>> future features related to FOREACH loop.
> So what you're saying is we need to allow ugliness now so we can have
> more ugliness in future? I don't find that a convincing
Merlin Moncure writes:
> On Fri, Dec 17, 2010 at 12:15 PM, Tom Lane wrote:
>> [ scratches head... ] I don't follow what you envision this doing,
>> exactly?
> It's like _pg_expandarray but alterted support multiple dimensions:
> select * from unnest_dims(array[['a','b'],['c','d']]) returns
> [
On 12/17/2010 12:15 PM, Pavel Stehule wrote:
2010/12/17 Itagaki Takahiro:
It should be not a main subject, but I remember there was a discussion
that "IN ARRAY array-expression" looks redundant for a literal array:
IN ARRAY ARRAY[1, 3, 5]
Are there any improvement for the issue?
yes. It
On Fri, Dec 17, 2010 at 12:15 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> another way:
>
>> FOREACH scalar IN ARRAY arr_exp DIMS in dim_var
>
>> dim_var being int[], or possibly text, of length #dimensions, giving
>> per dimesion index.
>
> [ scratches head... ] I don't follow what you envis
2010/12/17 Itagaki Takahiro :
> On Sat, Dec 18, 2010 at 02:03, Merlin Moncure wrote:
>>> FOREACH scalar-variable IN ARRAY array-expression
>>> FOR_EACH scalar-variable IN ARRAY array-expression
>>> FOR_SLICE array-variable [DEPTH n] IN ARRAY array-expression
>>> FOREACH
Merlin Moncure writes:
> another way:
> FOREACH scalar IN ARRAY arr_exp DIMS in dim_var
> dim_var being int[], or possibly text, of length #dimensions, giving
> per dimesion index.
[ scratches head... ] I don't follow what you envision this doing,
exactly?
I'm not thrilled with that specific
On Sat, Dec 18, 2010 at 02:03, Merlin Moncure wrote:
>> FOREACH scalar-variable IN ARRAY array-expression
>> FOR_EACH scalar-variable IN ARRAY array-expression
>> FOR_SLICE array-variable [DEPTH n] IN ARRAY array-expression
>> FOREACH scalar-variable IN ARRAY array-expr
2010/12/17 Merlin Moncure
> On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane wrote:
> > Pavel Stehule writes:
> >> 2010/12/17 Tom Lane :
> >>> Furthermore, it's underspecified: who's to say how many dimensions of
> >>> the array are supposed to get sliced off? There's no reasonable place
> >>> to ex
2010/12/17 Tom Lane :
> Pavel Stehule writes:
>> 2010/12/17 Tom Lane :
>>> Furthermore, it's underspecified: who's to say how many dimensions of
>>> the array are supposed to get sliced off? There's no reasonable place
>>> to extend this syntax to specify that. It will also be inconsistent
>>> f
On Fri, Dec 17, 2010 at 11:38 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> 2010/12/17 Tom Lane :
>>> Furthermore, it's underspecified: who's to say how many dimensions of
>>> the array are supposed to get sliced off? There's no reasonable place
>>> to extend this syntax to specify that. It wi
Pavel Stehule writes:
> 2010/12/17 Tom Lane :
>> Furthermore, it's underspecified: who's to say how many dimensions of
>> the array are supposed to get sliced off? Â There's no reasonable place
>> to extend this syntax to specify that. Â It will also be inconsistent
>> for "foreach scalar in array
2010/12/17 Tom Lane :
> Merlin Moncure writes:
>> On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane wrote:
>>> This seems like a really bad, confusing idea. I think it should throw
>>> a type-mismatch error in this case. If there is any use-case for such a
>>> thing, which I'm quite unconvinced of, it
Merlin Moncure writes:
> On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane wrote:
>> This seems like a really bad, confusing idea. I think it should throw
>> a type-mismatch error in this case. If there is any use-case for such a
>> thing, which I'm quite unconvinced of, it ought to use a separate syn
2010/12/17 Tom Lane :
> Pavel Stehule writes:
>> I am resending a redesigned proposal about special plpgsql statement
>> that support iteration over an array.
>
> OK ...
>
>> == Iteration over multidimensional arrays ==
>> Its designed to reduce one dimension from source array. It can remove
>> a
On Fri, Dec 17, 2010 at 10:47 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> I am resending a redesigned proposal about special plpgsql statement
>> that support iteration over an array.
>
> OK ...
>
>> == Iteration over multidimensional arrays ==
>> Its designed to reduce one dimension from sour
Pavel Stehule writes:
> I am resending a redesigned proposal about special plpgsql statement
> that support iteration over an array.
OK ...
> == Iteration over multidimensional arrays ==
> Its designed to reduce one dimension from source array. It can remove
> a slicing and simplify code:
This
2010/12/17 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of jue dic 16 16:19:17 -0300 2010:
>
>> The most performance issue of access to a untoasted array is "solved"
>> with other patch.
>
> Was the other patch applied?
>
no, it's in queue for next commitfest
https://commitfest.postg
Excerpts from Pavel Stehule's message of jue dic 16 16:19:17 -0300 2010:
> The most performance issue of access to a untoasted array is "solved"
> with other patch.
Was the other patch applied?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting,
Hello
I am resending a redesigned proposal about special plpgsql statement
that support iteration over an array.
The most conflict issue of last proposal was a syntax. It enhanced
relative complex FOR statement. So now, it's based on new statement
with simple syntax. We can use a keyword FOREACH,
33 matches
Mail list logo
