Re: [HACKERS] CONSTRAINTS...

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: jwieck(at)debis(dot)com
Cc: sferac(at)bo(dot)nettuno(dot)it, djackson(at)cpsgroup(dot)com, pgsql-hackers(at)hub(dot)org
Subject: Re: [HACKERS] CONSTRAINTS...
Date: 1999-01-13 11:23:25
Message-ID: 199901131123.GAA08966@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Ivar Helbekkmo 1999-01-13 13:04:41 Re: [HACKERS] postgres and year 2000
Previous Message Jan Wieck 1999-01-13 11:20:51 Re: [HACKERS] SUM() and GROUP BY