2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
>> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>>> ... So it might be possible to fix
>>> by attaching some new precedence level to the ROWS token.
>
>> Yes. Bison's default is to shift, whic
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
>> ... So it might be possible to fix
>> by attaching some new precedence level to the ROWS token.
> Yes. Bison's default is to shift, which means that if you do nothing it
> will treat R
On Tue, Oct 28, 2008 at 01:50:26PM -0400, Tom Lane wrote:
> > Given that the only problematic case is if expr_list ends with a
> > postfix operator, wouldn't it be sufficient to simply decree that in
> > that case you need parentheses? Seems a lot less painful than adding
> > two reserved words.
>
Martijn van Oosterhout <[EMAIL PROTECTED]> writes:
> On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
>> Right offhand, I don't see any alternative but to make both ROWS and
>> RANGE reserved. It's pretty annoying since that might break existing
>> applications that have been using these
On Tue, Oct 28, 2008 at 12:38:09PM -0400, Tom Lane wrote:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> > In window specifications, we have
>
> > OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
> > and currently "ROWS" is not reserved so bison is confused with cases
> > of "ROWS" included in e
2008/10/29 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> Can "ROWS" be reserved_keyword?
>
>> In window specifications, we have
>
>> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
>
>> and currently "ROWS" is not reserved so bison is confused with cases
>> of "ROWS"
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> Can "ROWS" be reserved_keyword?
> In window specifications, we have
> OVER (ORDER BY expr_list [(ROWS|RANGE) ... ])
> and currently "ROWS" is not reserved so bison is confused with cases
> of "ROWS" included in expr_list and in FRAME clause. Because
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> OK, I'll try to remove it. I'm not used to bison so my first task is
>> to find where the conflict is...
>
> Use bison -v to get details of where the conflict is. I find that
> the most common way to fix thi
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> OK, I'll try to remove it. I'm not used to bison so my first task is
> to find where the conflict is...
Use bison -v to get details of where the conflict is. I find that
the most common way to fix things is to postpone where the parser
has to make a
2008/10/28 Tom Lane <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> writes:
>> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>>> I tested the patch on mingw (Windows) and
>>> got the following warning and error:
>>>
>>> A. gram.y: conflicts: 3 shift/reduce
>>> B. include/nodes/planno
"Hitoshi Harada" <[EMAIL PROTECTED]> writes:
> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>> I tested the patch on mingw (Windows) and
>> got the following warning and error:
>>
>> A. gram.y: conflicts: 3 shift/reduce
>> B. include/nodes/plannodes.h:650: error: syntax error before "uint"
>>
2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>
> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>
>> And I fixed this problem, confirming with/without debug/cassert/gcc
>> -O and push it to git. If you want delta patch, please see
>> http://git.postgresql.org/?p=~davidfetter/window_functions/.git
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> And I fixed this problem, confirming with/without debug/cassert/gcc
> -O and push it to git. If you want delta patch, please see
> http://git.postgresql.org/?p=~davidfetter/window_functions/.git;a=commitdiff;h=fbf19bfd0c8d2ac083b775f4cc724ec66e74fa8f
2008/10/28 Hitoshi Harada <[EMAIL PROTECTED]>:
> Thanks for your testing all!
>
> 2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
>> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> select relid,AVG(seq_Scan) OVER (ORDER BY relid)
>>> FROM pg_stat_user_tables
>>> GROUP BY relid,seq_scan;
>>
>
Thanks for your testing all!
2008/10/28 ITAGAKI Takahiro <[EMAIL PROTECTED]>:
> "Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
>
>> As I promised, version 7 of the window functions is now released.
>> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
>
> I tested the patch on mingw
"Hitoshi Harada" <[EMAIL PROTECTED]> wrote:
> As I promised, version 7 of the window functions is now released.
> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
I tested the patch on mingw (Windows) and
got the following warning and error:
A. gram.y: conflicts: 3 shift/re
2008/10/28 David Rowley <[EMAIL PROTECTED]>:
> Hitoshi Harada Wrote:
>
>> As I promised, version 7 of the window functions is now released. At
>> the same time, git repository branch comes back to master.
>>
>> git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
>> patch: http://um
Hitoshi Harada Wrote:
> As I promised, version 7 of the window functions is now released. At
> the same time, git repository branch comes back to master.
>
> git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
> patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
As I promised, version 7 of the window functions is now released. At
the same time, git repository branch comes back to master.
git: http://git.postgresql.org/?p=~davidfetter/window_functions/.git
patch: http://umitanuki.net/pgsql/window_functions.patch.20081028.gz
It's too huge to send it to thi
19 matches
Mail list logo
