Re: [HACKERS] trouble with rules - Mailing list pgsql-hackers

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] trouble with rules
Date
Msg-id m109g0n-000EBRC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] trouble with rules  (Taral <taral@cyberjunkie.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] v6.4.3 ?
Next
From: Marc Howard Zuckman
Date:
Subject: Re: [SQL] Functional Indexes