# Re: more on delete from join

Date: Sun, 30 Aug 2009 10:27:15 -0700 (PDT)

Message-ID: <74fe01a5-0682-4831-b3cb-92aac8b42e44_at_t11g2000prh.googlegroups.com>

On Aug 30, 7:15 am, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

*> "Marshall" <marshall.spi..._at_gmail.com> wrote in message
*

> On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:

*>
**> > > 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.
**>
**> Then why did he bring up solving systems of equations in the
**> context of view updates?
*

Normally when we say someone has trouble telling two things apart, we mean that they are using them interchangeably without paying attention to their distinctions.

> > > 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.
**> >
**> The expressions are malformed in either sense.
*

They are your expressions. If you meant them as unparseable nonsense, then you cannot draw any conclusions from them.

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

OK. So that means you are using the things of which you said "definitely not equations" as equations. Is it possible that you are using assignment and equations interchangeably and not attending sufficiently to their differences?

> Doesn't the Assignment Principle require that the lhs of an assignment after

*> execution be equal to what the rhs evaluated to before?
*

I am unfamiliar with any "Assignment Principle." However what you describe does match the semantics of assignment in many imperative languages.

This stuff is not dogma. We can make up languages that do whatever we want; it is up to us to say what they do and to decide if they do what we want.

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

*> >
**> > No one has said anything about nondeterminism that I've seen.
**>
**> The system having to guess what the user intended is a direct
**> consequence of view updates being nondeterministic.
*

It is still the case that you are the only one bringing up
nondeterminism.

No one has proposed any nondeterministic semantics.

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