Re: [HACKERS] parser enhancement request for 6.5

From: jwieck(at)debis(dot)com (Jan Wieck)
To: lockhart(at)alumni(dot)caltech(dot)edu (Thomas Lockhart)
Cc: maillist(at)candle(dot)pha(dot)pa(dot)us, michael(dot)davis(at)prevuenet(dot)com, hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] parser enhancement request for 6.5
Date: 1999-05-10 16:28:49
Message-ID: m10gsvC-000EBXC@orion.SAPserv.Hamburg.dsh.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thomas Lockhart wrote:

> There is currently a single shift/reduce conflict in gram.y, and I'm
> suprised to find that it is *not* due to the "NULL_P '=' a_expr" line.
> I'm planning on touching gram.y to hunt down the shift/reduce conflict
> (from previous work I think it in Stefan's "parens around selects"
> mods), and I'll look at the NULL_P issue again also.

No - not the parens.

Looking at the y.output (produced with -v) I see that the
conflict is at state 266 when in the SelectStmt the FOR
keyword of FOR UPDATE has been seen. The SelectStmt is also
used in CursorStmt.

The rule cursor_clause in CursorStmt results in an
elog(ERROR) telling that cursors for update are not
supported. But in fact a

DECLARE x1 CURSOR FOR SELECT * FROM x FOR UPDATE OF x;

doesn't throw an error. So it is the CursorStmt's
cursor_clause that is currently unreachable in the parser.
Instead the SelectStmt's for_update_clause has already eaten
up the FOR UPDATE.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 1999-05-10 16:31:08 Re: [HACKERS] 64-bit hashjoins
Previous Message Bruce Momjian 1999-05-10 16:26:44 Re: [HACKERS] create view as select distinct (fwd)