Re: delete from jon

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:_zAom.42880$Db2.42221_at_edtnps83...
> Walter Mitty wrote:
> ....
>> Part of the problem with regard to sloppy language is that the term "view
>> update" is misleading. If view C is defined as A join B and one were to
>> apply an update, let's say MINUS D, what gets updated? If we were, in
>> reality, updating view C, then the update would be really simple. We
>> would update view C by changing its definition. The new definition of C
>> is (A join B) minus D. This might require making D be persistent, so
>> that the view can be applied later. Hey, presto! View C has just been
>> updated!
>>
>> But that's not what we really mean when we say "update view C". What we
>> mean is "leave view C defined exactly as before, but update A and B such
>> that the effect on C's apparent extension is the same as if the update
>> had been applied to a base relvar whose extension is the same as C's
>> apparent extension." Under this meaning of "update view C" the operation
>> is underconstrained, as has already been noted.
>
> I changed the subject back to delete from join because the above is not
> about insert to projection. They are very different problems (unlike
> delete from join, insert to projection is not just a matter of
> constraints).

Insert to projection is indeed underconstrained, provided the projection is non trivial.

When you insert into a projection, this means adding tuples to the relvar on which the projection is based. If there are attributes in the base relvar that are not present in the projection, then those attributes remain unspecified by the insert into the projection. They become "missing data" in the resulting tuples. That's underconstrained. Received on Mon Sep 07 2009 - 04:55:53 CEST