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