Re: Proposal / proof of concept: Triggers on VIEWs

From: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal / proof of concept: Triggers on VIEWs
Date: 2010-08-04 12:22:54
Message-ID: 4C595B9E.4000208@cs.helsinki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 8/4/10 2:39 PM +0300, Dean Rasheed wrote:
> Does this sound like a useful feature? Is this a sane approach to
> implementing it? If not, has anyone else given any thought as to how
> it might be implemented?

I didn't look at the patch, but so far, I've identified three problems
with the existing view system:

1) You can't re-evaluate the UPDATE expression like an UPDATE on a
table does. Consider for example UPDATE foo SET a=a+1; If the
tuples change before we get to them, we lose data because we
simply can't re-evaluate "a+1" in the trigger.

2) You can't set the number of affected rows.

3) You can't set the RETURNING results. You suggested that
RETURNING for DELETE would return the OLD value, but that seems
broken because that's not necessarily what was deleted. I didn't
understand what you suggestion for UPDATE was; how does PG know
that if the view doesn't have a primary key?

I think these are the main three problems that prevent people from
actually using views, and I think these should be focused on when adding
triggers on VIEWS. I would love to see the feature though.

Any thoughts?

Regards,
Marko Tiikkaja

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-08-04 12:23:36 Re: merge command - GSoC progress
Previous Message Heikki Linnakangas 2010-08-04 12:09:51 Re: merge command - GSoC progress