We're working on DBI-link which is an access method of sorts
using existing tools.
We want an empty local table foo with1. a _RETURN RULE2. an update TRIGGER3. a delete TRIGGER4. an insert TRIGGER
It seems we can have either the RULE or the TRIGGERs but not both.
We've tried tweaking relkind to fake it into thinking it was
a table after creating the _RETURN rule turned it into a view.
This didn't work. Apparently it (wisely?) checks
explicitly for a _RETURN rule when trying to create triggers.
Creating the triggers before the rule also did not fool it.
The reason we are using triggers for updates, etc. is that we
cannot access the iteration of the NEW/OLD rows in RULES.
A preferred solution would be to use the existing infrastructure
rather than adding, for example, a new relkind or a full blown
access method.
Also, what are the reasons for forbidding triggers on views?
It is to prevent *possible* mayhem or will it cause real problems?
Thanks,
elein
----- End forwarded message -----