Re: [HACKERS] CONSTRAINTS... - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: [HACKERS] CONSTRAINTS...
Date
Msg-id 199901131123.GAA08966@candle.pha.pa.us
Whole thread Raw
In response to Re: [HACKERS] CONSTRAINTS...  (jwieck@debis.com (Jan Wieck))
Responses Re: [HACKERS] CONSTRAINTS...  (jwieck@debis.com (Jan Wieck))
List pgsql-hackers
>     For  the  deferred  constraints  we  now   need   some   more
>     informations  on  the  rules  themself. Currently all queries
>     thrown in by the  rule  system  are  executed  prior  to  the
>     original  query.  If  we add some syntax to CREATE RULE so we
>     can tell
> 
>         CREATE [DEFERRABLE] [INITIALLY DEFERRED] RULE ...
> 
>     the rule system would be able to collect those queries  (they
>     all  would be RAISE statements) to a global querytree list if
>     they should be deferred.  This global  list  is  drained  out
>     (all  queries run) when either the transaction commits or the
>     SET ... IMMEDIATE is executed.
> 
>     Well, the information to remember isn't a small  amount.  Per
>     constraint  that  is  to  be  deferred,  there  will  be  one
>     querytree. And that for  every  single  INSERT/UPDATE/DELETE.
>     And  if  a  table  has 5 constraints, it will be 5 remembered
>     querytrees per operation. But  the  information  to  remember
>     doesn't  depend  on  the  amount  of  data  affected  in  the
>     statement (like it would be in a trigger implementation).  So
>     it will work in a situation like

Let's look at it another way.  If we didn't use the query rewrite
system, what method could we use for foreign key/contraints that would
function better than this?

As far as I remember, triggers are C functions?  We can't generate these
on the fly inside the backend.  (Though compiling C code from the
backend and dynamically linking it into the engine is way too cool.)

Could we generate generic triggers that would handle most/all
situations?  I don't know.  Even if we can, would they be much faster
than the needed queries themselves?  Seems triggers work on single
tables.  How do we span tables?  If it is going to launch queries from
the trigger, we should use the rewrite system.  It is better suited to
this, with predigested queries and queries that flow through the
executor in step with the user queries!

Maybe let's go with the rewrite system, because it works, and is
flexible and strangely designed for this type of problem.  Similar to
how we use the rewrite system for views.

I am basically asking for a reason _not_ to use the rewrite system for
this.  I can't think of one myself.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: jwieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] SUM() and GROUP BY
Next
From: Massimo Dal Zotto
Date:
Subject: Re: [HACKERS] postgres and year 2000