Re: parser dilemma

From: Zoltan Boszormenyi <zb(at)cybertec(dot)at>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: parser dilemma
Date: 2007-04-20 08:37:23
Message-ID: 46287BC3.5060005@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Andrew Dunstan írta:
> Zoltan Boszormenyi wrote:
>> Martijn van Oosterhout írta:
>>> On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
>>>
>>>>> The problem comes from cases like
>>>>>
>>>>> colname coltype DEFAULT 5! GENERATED ...
>>>>>
>>>>> Since b_expr allows postfix operators, it takes one more token of
>>>>> lookahead than we have to tell if the default expression is "5!"
>>>>> or "5!GENERATED ...".
>>>>>
>>>
>>> ISTM that as long as:
>>>
>>> colname coltype DEFAULT (5!) GENERATED ...
>>>
>>> works I don't see why it would be a problem to require the parentheses
>>> in this case. Postfis operators are not going to be that common here I
>>> think.
>>>
>>> Have a nice day,
>>>
>>
>> You mean like this one?
>> ------------------------------------------------------------------------
>> *** gram.y.old 2007-04-20 09:23:16.000000000 +0200
>> --- gram.y 2007-04-20 09:25:34.000000000 +0200
>> ***************
>> *** 7550,7557 ****
>> { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $2, $1, $3, @2); }
>> | qual_Op
>> b_expr %prec Op
>> { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $1, NULL, $2, @1); }
>> ! | b_expr
>> qual_Op %prec POSTFIXOP
>> ! { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $2, $1, NULL, @2); }
>> | b_expr IS DISTINCT FROM
>> b_expr %prec IS
>> {
>> $$ = (Node *)
>> makeSimpleA_Expr(AEXPR_DISTINCT, "=", $1, $5, @2);
>> --- 7550,7557 ----
>> { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $2, $1, $3, @2); }
>> | qual_Op
>> b_expr %prec Op
>> { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $1, NULL, $2, @1); }
>> ! | '(' b_expr qual_Op
>> ')' %prec POSTFIXOP
>> ! { $$ = (Node *) makeA_Expr(AEXPR_OP,
>> $3, $2, NULL, @3); }
>> | b_expr IS DISTINCT FROM
>> b_expr %prec IS
>> {
>> $$ = (Node *)
>> makeSimpleA_Expr(AEXPR_DISTINCT, "=", $1, $5, @2);
>> ------------------------------------------------------------------------
>>
>> This change alone brings 13 reduce/reduce conflicts.
>>
>>
>
> No - that's not what you do. All you need to do is remove those 2
> lines from the b_expr rules. The postfix rule will still be in a_expr
> and the parenthesized bit is taken care of in the ( a_expr ) rule for
> c_expr.
>
> cheers
>
> andrew

I just sent a new patch that marks GENERATED as %right,
which also solved the problem.

Best regards,
Zoltán

--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marcin Waldowski 2007-04-20 08:41:59 Re: BUG #3242: FATAL: could not unlock semaphore: error code 298
Previous Message Zoltan Boszormenyi 2007-04-20 08:35:29 Re: [HACKERS] parser dilemma

Browse pgsql-patches by date

  From Date Subject
Next Message Koichi Suzuki 2007-04-20 09:13:52 Re: [HACKERS] Full page writes improvement, code update
Previous Message Zoltan Boszormenyi 2007-04-20 08:35:29 Re: [HACKERS] parser dilemma