> 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....
True, and it works well enough for a view joining two tables. However, if you
want to join more
than two tables in a view you have to create additional Nested Views one for
each joined child
table in order to cascade updates down to each of these tables. This way each
child table's ctid
can be directly referenced in it own view so there is no ambiguity. As you can
imagine, creating
these additional updatable views with associated rules for cascading updates
requires a voluminous
amount of DDL code. At least this is what my current experimenting has lead me
to believe.
Perhaps there is a better logical model with can achieve what I want from an
updatable view
without the additional overhead that I am creating. Any suggests or
corrections on this topic are
very much welcomed.
The advantage on the otherhand with method this of-course is that the finial
result is a view that
appears to preform exactly like a table for single tuple insert, update, and
delete statements.
My feature request is based on the assertion that single updatable view on
multiple tables joined
with simply an inner join based on surrogate integer primary keys shouldn't
require the additional
overhead that I am now creating.
Regards,
Richard Broersma Jr.
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org/
