We'd want the tuples to be produced by the select rule
and treated as if we didn't care where they came from.
Perhaps it doesn't work this way because of the way srfs
were integrated into the SQL execution? I dunno.
do instead triggers should be deemed safe on a view
for those brave enough to try.
The base problem still is having the iterations of OLD and
NEW available in rules--sort of the opposite problem of implementing
per statement triggers.
But we may have a solution still by having rules on the
view and triggers on a table and marrying them via the
update insert delete rules. We'll see how it goes.
This was suggested over on irc.
Thank you...More news as it happens.
--elein
On Sun, Dec 05, 2004 at 06:02:00PM -0500, Tom Lane wrote:
> elein <elein@varlena.com> writes:
> > Also, what are the reasons for forbidding triggers on views?
>
> The fact that they'd never fire (or better never fire). A view does not
> actually store any tuples, so update and delete triggers on it are
> certainly useless. You could imagine allowing BEFORE INSERT triggers,
> with the understanding that nothing will be inserted no matter what the
> trigger returns ... but such a trigger is still useless unless we remove
> the safety restriction that says you can't INSERT into a view without
> having an ON INSERT DO INSTEAD rule.
>
> What you are probably wishing you had is some sort of ability to trigger
> on "virtual", pre-rewriter operations, but the executor and the trigger
> mechanism know nothing of this.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>
