# Re: more on delete from join

Date: Sun, 30 Aug 2009 14:24:01 -0700 (PDT)

Message-ID: <7669561e-6451-4638-89fc-c5ac24375323_at_o36g2000vbl.googlegroups.com>

On Aug 30, 3:31 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

> Kevin Kirkpatrick wrote:

*> > On Aug 30, 12:39 am, Marshall <marshall.spi..._at_gmail.com> wrote:
**>
**> >>On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
**>
**> >>>"Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
**>
**> >>>news:cb3a626b-70c1-44ca-aec2-7a65cb69aa45_at_h30g2000vbr.googlegroups.com...
**>
**> >>><snip>
**>
**> >>>>I'm not saying the notion of a programming language solving systems of
**> >>>>equations is undesirable. But I am saying that the language needs
**> >>>>more than just assignments to get you there.
**>
**> >>>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.
**>
**> >>>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.
**>
**> >>>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?
**>
**> >>>I think it defies logic for assignment to be anything but deterministic.
**>
**> >>No one has said anything about nondeterminism that I've seen.
**>
**> >>Marshall
**>
**> > On Aug 30, 12:27 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
**>
**> >>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?
**>
**> >>Probably because there are many interesting things to learn
**> >>from considering view updates as being related to solving
**> >>systems of equations.
**>
**> >>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.
**>
**> >>That would be one way to do it, but you are the only one talking about
**> >>doing it that way, and it is, as you say, a poor choice of how to do
**> >>it.
**> >>This is what's called a strawman argument.
**>
**> >>Some systems of equations are overspecified, some are underspecified,
**> >>and some are uniquely specified. Which one of those do you think
**> >>might be a good candidate for the kind of view update that
**> >>would succeed? Would fail?
**>
**> >>Marshall
**>
**> > Okay, I'll take another stab at this.
**>
**> > BASE RELATION T := {TUPLE {C1='X'}};
**>
**> > VIRTUAL RELATION V := 'T';
**>
**> > INSERT INTO V {TUPLE {C1='Y'}}
**>
**> > There seem to be two ideas of how a statement like this, if allowed
**> > into the langauge, could be interpretted.
**>
**> > First, there's the relational assignment interpretation, which
**> > attempts to treat this insert into V exactly as if it were an insert
**> > into a base table. My objection to this interpretation was: an INSERT
**> > into a base table can be considered a shorthand for an assignment to a
**> > base table. However, if one attempts to turn the INSERT into V into
**> > an assignment, one gets a view variable on the left hand side and a
**> > relation-value on the right-hand-side, which is clearly a nonsensical
**> > type-violation.
**>
**> Not so. A view is a named relation variable.- Hide quoted text -
**>
**> - Show quoted text -
*

On Aug 30, 3:31 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

> Kevin Kirkpatrick wrote:

*> > On Aug 30, 12:39 am, Marshall <marshall.spi..._at_gmail.com> wrote:
**>
**> >>On Aug 29, 12:30 pm, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
**>
**> >>>"Kevin Kirkpatrick" <kvnkrkpt..._at_gmail.com> wrote in message
**>
**> >>>news:cb3a626b-70c1-44ca-aec2-7a65cb69aa45_at_h30g2000vbr.googlegroups.com...
**>
**> >>><snip>
**>
**> >>>>I'm not saying the notion of a programming language solving systems of
**> >>>>equations is undesirable. But I am saying that the language needs
**> >>>>more than just assignments to get you there.
**>
**> >>>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.
**>
**> >>>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.
**>
**> >>>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?
**>
**> >>>I think it defies logic for assignment to be anything but deterministic.
**>
**> >>No one has said anything about nondeterminism that I've seen.
**>
**> >>Marshall
**>
**> > On Aug 30, 12:27 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
**>
**> >>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?
**>
**> >>Probably because there are many interesting things to learn
**> >>from considering view updates as being related to solving
**> >>systems of equations.
**>
**> >>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.
**>
**> >>That would be one way to do it, but you are the only one talking about
**> >>doing it that way, and it is, as you say, a poor choice of how to do
**> >>it.
**> >>This is what's called a strawman argument.
**>
**> >>Some systems of equations are overspecified, some are underspecified,
**> >>and some are uniquely specified. Which one of those do you think
**> >>might be a good candidate for the kind of view update that
**> >>would succeed? Would fail?
**>
**> >>Marshall
**>
**> > Okay, I'll take another stab at this.
**>
**> > BASE RELATION T := {TUPLE {C1='X'}};
**>
**> > VIRTUAL RELATION V := 'T';
**>
**> > INSERT INTO V {TUPLE {C1='Y'}}
**>
**> > There seem to be two ideas of how a statement like this, if allowed
**> > into the langauge, could be interpretted.
**>
**> > First, there's the relational assignment interpretation, which
**> > attempts to treat this insert into V exactly as if it were an insert
**> > into a base table. My objection to this interpretation was: an INSERT
**> > into a base table can be considered a shorthand for an assignment to a
**> > base table. However, if one attempts to turn the INSERT into V into
**> > an assignment, one gets a view variable on the left hand side and a
**> > relation-value on the right-hand-side, which is clearly a nonsensical
**> > type-violation.
**>
**> Not so. A view is a named relation variable.- Hide quoted text -
**>
**> - Show quoted text -
*

Hmm - perhaps I'm confused on the terminology, but I thought a "named relation variable" was a base relvar, and virtual relvars (aka views) were "named relation expressions". By this distinction, base relvars are assigned relation values

relvar (HEADING {C1 CHAR(1)}) A := {TUPLE {C1='Y'}}

and virtual relvars are assigned relational expressions;

view V := 'A UNION B' Received on Sun Aug 30 2009 - 23:24:01 CEST