Re: [HACKERS] trouble with rules
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] trouble with rules |
Дата | |
Msg-id | m109g0n-000EBRC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] trouble with rules (Taral <taral@cyberjunkie.com>) |
Список | pgsql-hackers |
> > On Sun, 07 Feb 1999, you wrote: > > Hmmm - wasn't there some switch to bison that tells where it > > shifts/reduces. I know most of the features of gdb, but bison > > is a bit hairy for me. > > bison -v will spit out a *huge* data file describing the parser. Somewhere in > there it will tell you where the shift/reduce conflict is occurring. > > Taral Thanks Taral, and bingo - Tom's guess about that it came with INTERSECT seems right. [...] State 269 contains 1 shift/reduce conflict. [...] state 269 SelectStmt -> select_w_o_sort sort_clause . for_update... I'm currently committing the turn backs into rewriteManip.c and the additional rule system tests. INTERSECT IS BROKEN NOW!!! The one who's responsible for that may contact me to help fixing it by doing the comparisions that rely on memory addresses of Var nodes correctly according to the requirements of the rule system. I don't know enough about how INTERSECT/EXCEPT is expected to work. And the regression test, which is passing here now completely (only the 4 missing NOTICE in misc) seems not cover it. 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 по дате отправления: