Request for new function in view update

Hello all,

I am a researcher in databases who would like to suggest a new function. I
am writing to you because you have an active developer community. Your
website said that suggestions for new functions should go to this mailing
list. If there is another mailing list you prefer, please let me know.

My research is in updating views -- the problem of translating an update in
a view to an update to a set of underlying base tables. This problem has
been partially solved for many years, including in PostgreSQL, but a
complete solution hasn't been found.

Views are useful for data independence; if users only access data through
views, then underlying databases can change without user programs. Data
independence requires an automatic solution to the view update problem.

In my research, I went back to the initial papers about the problem. The
most promising approach was the "constant complement" approach. It starts
from the idea that a view shows only part of the information in a database,
and that view updates should never change the part of the database that
isn't exposed in the view. (The "complement" is the unexposed part, and
"constant" means that a view update shouldn't change the complement.) The
"constant complement" constraint is intuitive, that a view update shouldn't
have side effects on information not available through the view.

A seminal paper showed that defining a complement is enough, because each
complement of a view creates a unique view update. Unfortunately, there
are limitations. Views have multiple complements, and no unique minimal
complement exists. Because of this limitation and other practical
difficulties, the constant complement approach was abandoned.

I used a theorem in this initial paper that other researchers didn't use,
that shows the inverse. An update method defines a unique complement. I
used the two theorems as a saw's upstroke and downstroke to devise view
update methods for several relational operators. Unlike other approaches,
these methods have a solid mathematical foundation.

Some relational operators are easy (selection), others are hard
(projection); some have several valid update methods that can be used
interchangeably (union) and some can have several valid update methods that
reflect different semantics (joins). For joins, I found clues in the
database that can determine which update method to use. I address the
other relational operators, but not in the attached paper
.
I also discuss the problem of when views can't have updates, and possible
reasons why.

I have attached my arXiv paper. I would appreciate anyone's interest in
this topic.

Yours
Terry Brennan