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