# Re: more on delete from join

Date: Sun, 30 Aug 2009 10:15:41 -0400

Message-ID: <jdqdnW3ao8YQFAfXnZ2dnUVZ_v-dnZ2d_at_giganews.com>

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:2b128d1f-7303-4890-b591-45868329f4d9_at_g1g2000pra.googlegroups.com... On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

<quote>

> I think you're making the same mistake as Bob. Assignments aren't

*> equations.
*

I see no evidence that Bob has trouble telling assignments and
equations apart.

</quote>

Then why did he bring up solving systems of equations in the context of view updates?

<quote>

*> x := x + 1 definitely not an equation.
*

Of course it isn't.

> It may be desirable to have a programming language that can solve systems

*> of
**> equations, but....
**>
**> x + y := 3 definitely not an equation.
**> x - y := 1 definitely not an equation.
*

Whether it is an equation or not depends on what those
symbols you typed are supposed to mean. So far all
you've said is that they aren't equations. However they
are both closer in form to equations than to assignments,
according to custom.

</quote>

The expressions are malformed in either sense.

<quote>

> The result?

*>
**> x = 2 and y = 1? possible.
**> x = 503423 and y = 503422? also possible.
**> x = -324 and y = -325 also possible.
*

But you said above that they were *not* equations,
so where are you deriving these from?

</quote>

They are not derived. They are picked out at random from the infinite combinations of values that add up to 1, the rhs of the final assignment. Doesn't the Assignment Principle require that the lhs of an assignment after execution be equal to what the rhs evaluated to before?

<quote>

*> I think it defies logic for assignment to be anything but deterministic.
*

No one has said anything about nondeterminism that I've seen. </quote>

The system having to guess what the user intended is a direct consequence of view updates being nondeterministic. For example, an insert into a union view involving two tables is not deterministic because there are three different combinations of values that could result in the same value for the view. The system has to guess whether the row must be inserted into one table or the other or both. The same can be said of a delete from a join view. Received on Sun Aug 30 2009 - 16:15:41 CEST