From: | Andreas Zeugswetter <andreas(dot)zeugswetter(at)telecom(dot)at> |
---|---|
To: | "'Jan Wieck'" <jwieck(at)debis(dot)com> |
Cc: | "'hackers(at)postgresql(dot)org'" <hackers(at)postgresql(dot)org> |
Subject: | Re: AW: [HACKERS] Rule system |
Date: | 1998-08-12 15:38:41 |
Message-ID: | 01BDC618.BDD6D610@zeugswettera.user.lan.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> But then again, even if functions stay that restricted, what
> do we need as rule functionality? Up to now I only have all
> kinds of INSTEAD rules on the statement level on my list.
The [select] trigger can't return sets/tuples or multiple rows the select rule system can.
This is because of the currently restricted "create function" return values.
I'll try to look over my diploma paper tonight, to look for rules that (at least currently)
cannot be written as triggers (other than instead rules).
What I like about the rewrite sytem is, that it passes through the optimizer.
No way the trigger stuff is going to be optimizable, is it ? It will always do something like
a nested loop.
Please let's not get rid of rules until we have the full trigger functionality discussed earlier,
even if it does behave strangely in some cases, it is still very usable.
I think the select rule stuff is mostly working since your last changes ;-)
Maybe we could add syntax to the trigger statement to simply use the current
select rule stuff ?
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1998-08-12 16:41:39 | Re: [HACKERS] Re: type coersion (was OR clause status) |
Previous Message | t-ishii | 1998-08-12 14:46:22 | Re: [HACKERS] 6.3.2. patch for functional indices |