Re: feature request for Postgresql Rule system.

From: Bernd Helmle <mailings(at)oopsware(dot)de>
To: Richard Broersma Jr <rabroersma(at)yahoo(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org
Subject: Re: feature request for Postgresql Rule system.
Date: 2006-12-19 18:23:26
Message-ID: 4d621b9def6d19bd52b3e1ef7c0b5995@oopsware.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, 19 Dec 2006 07:22:36 -0800 (PST), Richard Broersma Jr <rabroersma(at)yahoo(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Angva 2006-12-19 18:52:50 Re: out of memory woes
Previous Message Bernd Helmle 2006-12-19 18:03:13 Re: Savepoints in PL/pgSQL