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

From jwieck@debis.com (Jan Wieck)
Subject Re: [HACKERS] trouble with rules
Date
Msg-id m109dLQ-000EBPC@orion.SAPserv.Hamburg.dsh.de
Whole thread Raw
In response to Re: [HACKERS] trouble with rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] trouble with rules  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
Tom Lane wrote:

> jwieck@debis.com (Jan Wieck) writes:
> >         It looks to me, that  it  was  taken  out  only  to  move
> >         INTERSECT in the easy way.  But this time the easy way is
> >         IMHO the wrong way.
> >         Removing a documented, released feature is something that
> >         causes  havy  trouble  for those who want to upgrade to a
> >         new version.
> >         Next time  please  keep  existing  syntax/features  until
> >         there  is an agreement of the developers team that it has
> >         to die.
>
> Calm down Jan ;-).  I think what happened here is a slightly careless
> merge of the 6.3 - based INTERSECT/EXPECT code into the current code.
> Not a deliberate removal of a feature, just a foulup.

    Was  my fault too. I should have added this new syntax to the
    regression (as I did now). That way I would have  noticed  as
    early as can that something disappeared.

>
> This does suggest that we need to be more careful when applying patches
> developed against old system versions.

    This does suggest that we need to pay more attention that all
    the nifty things we do are added to the regression suite.

    Saying this I've just checked and the examples  I've  written
    in  the  rule  system section of the programmers manual cause
    the backend to dump core.

    Isn't if funny? All I'm telling could be used against me. :-)

>
> >     BTW: There is 1 shift/reduce conflict in  gram.y  (was  there
> >     before I fixed multi action rules). Who introduced that?
>
> Yeah, I'm seeing that too.  Same cause perhaps?  It seems to have
> appeared in rev 2.43, when the INTERSECT/EXPECT code was checked in.

    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.


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: gjerde@icebox.org
Date:
Subject: RE: [HACKERS] Problems with >2GB tables on Linux 2.0
Next
From: Peter T Mount
Date:
Subject: RE: [HACKERS] Problems with >2GB tables on Linux 2.0