Andrew - Supernews <[EMAIL PROTECTED]> writes:
> Use two tables. One has rules, the other has the trigger. (Neither store
> any data.) Here's a working example (tested on 7.4.5):
> -- declare the table which we're going to be manipulating. This never
> -- actually stores anything (it becomes a vie
On 2004-12-05, elein <[EMAIL PROTECTED]> wrote:
> We're working on DBI-link which is an access method of sorts
> using existing tools.
>
> We want an empty local table foo with
> 1. a _RETURN RULE
> 2. an update TRIGGER
> 3. a delete TRIGGER
> 4. an insert TRIGGER
Use two t
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
elein <[EMAIL PROTECTED]> 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
We're working on DBI-link which is an access method of sorts
using existing tools.
We want an empty local table foo with
1. a _RETURN RULE
2. an update TRIGGER
3. a delete TRIGGER
4. an insert TRIGGER
It seems we can have either the RULE or the TRIGGERs but not bot
