Re: WIP: Triggers on VIEWs

Bernd Helmle <mailings@oopsware.de>

From: Bernd Helmle <mailings@oopsware.de>
To: Dean Rasheed <dean.a.rasheed@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-09-22T22:16:52Z
Lists: pgsql-hackers

--On 5. September 2010 09:09:55 +0100 Dean Rasheed 
<dean.a.rasheed@gmail.com> wrote:

I had a first look on your patch, great work!

> Attached is an updated patch with more tests and docs, and a few minor
> code tidy ups. I think that the INSTEAD OF triggers part of the patch
> is compliant with Feature T213 of the SQL 2008 standard. As discussed,

Reading the past discussions, there was some mention about the RETURNING 
clause.
I see Oracle doesn't allow its RETURNING INTO clause with INSTEAD OF 
triggers (at least my 10g XE instance here doesn't allow it, not sure about 
newer versions). I assume the following example might have some surprising 
effects on users:

CREATE TABLE foo(id integer);
CREATE VIEW vfoo AS SELECT 'bernd', * FROM foo;	

CREATE OR REPLACE FUNCTION insert_foo() RETURNS trigger
LANGUAGE plpgsql
AS $$
        BEGIN INSERT INTO foo VALUES(NEW.id);
	RETURN NEW;
END; $$;

CREATE TRIGGER insert_vfoo INSTEAD OF INSERT ON vfoo
        FOR EACH ROW EXECUTE PROCEDURE insert_foo();

INSERT INTO vfoo VALUES('helmle', 2) RETURNING *;
  text  | id
--------+----
 helmle |  2
(1 row)

SELECT * FROM vfoo;
 text  | id
-------+----
 bernd |  2
(1 row)

This is solvable by a properly designed trigger function, but maybe we need 
to do something about this?

> I don't plan to add the syntax to allow triggers on views to be
> disabled at this time, but that should be easy to implement, if there
> is a use case for it.

I really don't see a need for this at the moment. We don't have DISABLE 
RULE either. I'm going to post some additional comments once i've 
understand all things.

-- 
Thanks

	Bernd