Re: AW: [HACKERS] Rule system

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

Browse pgsql-hackers by date

  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