Re: [HACKERS] parser enhancement request for 6.5
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] parser enhancement request for 6.5 |
Дата | |
Msg-id | m10gsvC-000EBXC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] parser enhancement request for 6.5 (Thomas Lockhart <lockhart@alumni.caltech.edu>) |
Список | 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@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: