rules, triggers and views

From: elein <elein(at)varlena(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: elein <elein(at)varlena(dot)com>, David Fetter <david(at)fetter(dot)org>
Subject: rules, triggers and views
Date: 2004-12-05 22:27:14
Message-ID: 20041205142714.B17708@cookie.varlena.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 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 -----

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2004-12-05 22:32:34 Re: Error: column "nsptablespace" does not exist
Previous Message Kurt Roeckx 2004-12-05 21:25:43 Re: Need access to a Linux box