From: | Zoltan Boszormenyi <zb(at)cybertec(dot)at> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | 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>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: parser dilemma |
Date: | 2007-04-20 07:27:46 |
Message-ID: | 46286B72.5080802@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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.
Best regards
--
----------------------------------
Zoltán Böszörményi
Cybertec Geschwinde & Schönig GmbH
http://www.postgresql.at/
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-04-20 07:51:10 | Re: BUG #3242: FATAL: could not unlock semaphore: error code 298 |
Previous Message | Marcin Waldowski | 2007-04-20 07:20:05 | Re: BUG #3242: FATAL: could not unlock semaphore: error code 298 |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2007-04-20 07:46:28 | actualised forgotten Magnus's patch for plpgsql MOVE statement |
Previous Message | Koichi Suzuki | 2007-04-20 06:00:15 | Re: [HACKERS] Full page writes improvement, code update |