Re: feature request for Postgresql Rule system. - Mailing list pgsql-general

From Bernd Helmle
Subject Re: feature request for Postgresql Rule system.
Date
Msg-id 4d621b9def6d19bd52b3e1ef7c0b5995@oopsware.de
Whole thread Raw
In response to Re: feature request for Postgresql Rule system.  (Richard Broersma Jr <rabroersma@yahoo.com>)
Responses Re: feature request for Postgresql Rule system.  (Richard Broersma Jr <rabroersma@yahoo.com>)
List pgsql-general


On Tue, 19 Dec 2006 07:22:36 -0800 (PST), Richard Broersma Jr <rabroersma@yahoo.com> wrote:

>> Once you update one side of the join with a
>> different join key value, the join row in question no longer exists in
>> the view ... so the second update doesn't find a row to update.  This
>> has nothing to do with ACID.
> I see,  ACID wasn't the correct word choice to use.  I realize that the
> rule system can have many
> uses and allowing views to become updatable is just one of its many uses.
> But if a view is going
> to be updatable, shouldn't behave exactly as a table would to at least for
> single tuple insert,
> update, and delete statements?

I've already thought about that while dealing with auto-updatable views. You'd have
to provide a view update rule with a consistent "snapshot" on your view data during update
while updating the underlying base tables. I haven't dug into this deeper since i was
concentrated on updatable views on single base tables only. However, the rule system already
adds the CTID TE to the query tree and it looks to me this can be extended to provide
the requested behavior. The way the rewriter handles it's query qualifications would have to
be redesigned as well, i think, but i don't know what can of worms there are, too....



Bernd

pgsql-general by date:

Previous
From: Chris Browne
Date:
Subject: Re: Autovacuum Improvements
Next
From: Richard Broersma Jr
Date:
Subject: Re: feature request for Postgresql Rule system.