Thread

  1. trouble with rules

    Erich Stamberger <eberger@gewi.kfunigraz.ac.at> — 1999-02-02T05:05:40Z

    Hi!
    
    can somebody see this too?
    
    create table t1(i1 int4);
    create table t2(i1 int4);
    create table t3(i2 int4);
    
    test=> create rule rm_t1 as on delete to t1 
    test-> do ( delete from t2 where old.i1 = i1;
    test->      delete from t3 where old.i1 = i2;);
    pqReadData() -- backend closed the channel unexpectedly.
            This probably means the backend terminated abnormally before or
    while processing the request.
    We have lost the connection to the backend, so further processing is
    impossible.  Terminating.
    
    
    OS = Linux 2.0.35, gcc 2.7.2.3, postgreSQL-6.4.2
    
    
    Regards
    Erich
    
    
    
  2. Re: [HACKERS] trouble with rules

    Jan Wieck <jwieck@debis.com> — 1999-02-02T10:03:47Z

    >
    > Hi!
    >
    > can somebody see this too?
    >
    > create table t1(i1 int4);
    > create table t2(i1 int4);
    > create table t3(i2 int4);
    >
    > test=> create rule rm_t1 as on delete to t1
    > test-> do ( delete from t2 where old.i1 = i1;
    > test->      delete from t3 where old.i1 = i2;);
    > pqReadData() -- backend closed the channel unexpectedly.
    >         This probably means the backend terminated abnormally before or
    > while processing the request.
    > We have lost the connection to the backend, so further processing is
    > impossible.  Terminating.
    >
    >
    > OS = Linux 2.0.35, gcc 2.7.2.3, postgreSQL-6.4.2
    
        That's  courios.  I  can't  reproduce  it with v6.4 or v6.4.2
        (Linux 2.1.88, gcc 2.7.2.1). Did the checks with the  release
        tarballs,  not with the REL_6_4 tree (will check that later).
    
        But with the current development tree I  get  a  parse  error
        near delete!
    
        I  recall  that  there was something done in the parser about
        parantheses around queries. Have to check it out and if fixed
        add  multiple action rules with parantheses to the regression
        test to avoid breakage again in the future.
    
    
    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) #
    
    
    
    
  3. Re: [HACKERS] trouble with rules

    Vadim Mikheev <vadim@krs.ru> — 1999-02-02T10:13:40Z

    Jan Wieck wrote:
    > 
    > >
    > > Hi!
    > >
    > > can somebody see this too?
    > >
    > > create table t1(i1 int4);
    > > create table t2(i1 int4);
    > > create table t3(i2 int4);
    > >
    > > test=> create rule rm_t1 as on delete to t1
    > > test-> do ( delete from t2 where old.i1 = i1;
    > > test->      delete from t3 where old.i1 = i2;);
    > > pqReadData() -- backend closed the channel unexpectedly.
    > >         This probably means the backend terminated abnormally before or
    > > while processing the request.
    > > We have lost the connection to the backend, so further processing is
    > > impossible.  Terminating.
    > >
    > >
    > > OS = Linux 2.0.35, gcc 2.7.2.3, postgreSQL-6.4.2
    > 
    >     That's  courios.  I  can't  reproduce  it with v6.4 or v6.4.2
    >     (Linux 2.1.88, gcc 2.7.2.1). Did the checks with the  release
    >     tarballs,  not with the REL_6_4 tree (will check that later).
    
    CASSERT is off?
    
    Vadim
    
    
  4. Re: [HACKERS] trouble with rules

    Jan Wieck <jwieck@debis.com> — 1999-02-02T13:08:05Z

    Vadim wrote:
    
    >
    > Jan Wieck wrote:
    > >
    > > >
    > > > Hi!
    > > >
    > > > can somebody see this too?
    > > >
    > > > create table t1(i1 int4);
    > > > create table t2(i1 int4);
    > > > create table t3(i2 int4);
    > > >
    > > > test=> create rule rm_t1 as on delete to t1
    > > > test-> do ( delete from t2 where old.i1 = i1;
    > > > test->      delete from t3 where old.i1 = i2;);
    > > > pqReadData() -- backend closed the channel unexpectedly.
    > > >         This probably means the backend terminated abnormally before or
    > > > while processing the request.
    > > > We have lost the connection to the backend, so further processing is
    > > > impossible.  Terminating.
    > > >
    > > >
    > > > OS = Linux 2.0.35, gcc 2.7.2.3, postgreSQL-6.4.2
    > >
    > >     That's  courios.  I  can't  reproduce  it with v6.4 or v6.4.2
    > >     (Linux 2.1.88, gcc 2.7.2.1). Did the checks with the  release
    > >     tarballs,  not with the REL_6_4 tree (will check that later).
    >
    > CASSERT is off?
    
        Yepp - thanks.
    
        Fixed in REL6_4 and CURRENT.
    
        Placed a patch in
    
            ftp://hub.org/pub/patches/multi_action_rule.patch
    
        Now  have  to  look who damaged the parser in CURRENT not any
        longer accepting parentheses for mutiple action rules.
    
    
    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) #
    
    
    
    
  5. Re: [HACKERS] trouble with rules

    Jan Wieck <jwieck@debis.com> — 1999-02-07T19:41:10Z

    > > > > can somebody see this too?
    > > > >
    > > > > create table t1(i1 int4);
    > > > > create table t2(i1 int4);
    > > > > create table t3(i2 int4);
    > > > >
    > > > > test=> create rule rm_t1 as on delete to t1
    > > > > test-> do ( delete from t2 where old.i1 = i1;
    > > > > test->      delete from t3 where old.i1 = i2;);
    > > > > pqReadData() -- backend closed the channel unexpectedly.
    >
    >     Now  have  to  look who damaged the parser in CURRENT not any
    >     longer accepting parentheses for mutiple action rules.
    
        Has been commented out when INTERSECT came.
    
        Fixed in CURRENT. I hate to but I have to comment on this:
    
            Beeing  able  to  put  multiple  actions  for  rules into
            parentheses has been added and RELEASED  with  v6.4.  And
            this  syntax  is  documented in the programmers manual of
            v6.4.
    
            It wasn't hard to reenable it. I just told gram.y that  a
            SelectStmt  cannot occur in a multiple rule action block.
            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.
    
        BTW: There is 1 shift/reduce conflict in  gram.y  (was  there
        before I fixed multi action rules). Who introduced that?
    
    
    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) #
    
    
    
    
  6. Re: [HACKERS] trouble with rules

    Michael Meskes <michael_meskes@topmail.de> — 1999-02-08T07:45:16Z

    On Sun, Feb 07, 1999 at 08:41:10PM +0100, Jan Wieck wrote:
    >     BTW: There is 1 shift/reduce conflict in  gram.y  (was  there
    >     before I fixed multi action rules). Who introduced that?
    
    Don't know but it was introduced with the EXCEPT and INTERSECT features.
    I haven't found the time yet to check where it comes from. But the same
    holds for ecpg since I synced both yacc files.
    
    Michael
    -- 
    Michael Meskes                         | Go SF 49ers!
    Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
    Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
    Email: Michael.Meskes@gmx.net          | Use PostgreSQL!