Re: WIP: Triggers on VIEWs

--On 30. September 2010 07:38:18 +0100 Dean Rasheed
<dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:

>> This version doesn't apply clean anymore due to some rejects in
>> plainmain.c. Corrected version attached.
>>
>
> Ah yes, those pesky bits have been rotting while I wasn't looking.
> Thanks for fixing them!

Basic summary of this patch:

* The patch includes a fairly complete discussion about INSTEAD OF triggers
and their usage on views. There are also additional enhancements to the
RULE documentation, which seems, given that this might supersede the usage
of RULES for updatable views, reasonable.

* The patch passes regressions tests and comes with a bunch of its own
regression tests. I think they are complete, they cover statement and row
Level trigger and show the usage for JOINed views for example.

* I've checked against a draft of the SQL standard, the behavior of the
patch seems to match the spec (my copy might be out of date, however).

* The code looks pretty good to me, there are some low level error messages
exposing some implementation details, which could be changed (e.g.
"wholerow is NULL"), but given that this is most of the time unexpected and
is used in some older code as well, this doesn't seem very important.

* The implementation introduces the notion of "wholerow". This is a junk
target list entry which allows the executor to carry the view information
to an INSTEAD OF trigger. In case of DELETE/UPDATE, the rewriter is
responsible to inject the new "wholerow" TLE and make the original query to
point to a new range table entry (correct me, when i'm wrong), which is
based on the view's query. I'm not sure i'm happy with the notion of
"wholerow" here, maybe "viewrow" or "viewtarget" is more descriptive?

* I'm inclined to say that INSTEAD OF triggers have less overhead than
RULES, but this is not proven yet with a reasonable benchmark.

I would like to do some more tests/review, but going to mark this patch as
"Ready for Committer", so that someone more qualified on the executor part
can have a look on it during this commitfest, if that's okay for us?

--
Thanks

Bernd