Re: more on delete from join

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