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