Re: more on delete from join

From: Kevin Kirkpatrick <kvnkrkptrck_at_gmail.com>
Date: Sun, 30 Aug 2009 13:08:42 -0700 (PDT)
Message-ID: <486f53f2-10fd-4d4b-af45-be256f187ed3_at_r34g2000vba.googlegroups.com>


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. I'd been trying to make this absurdity more apparent by introducing a hypothetical, stripped-down language and demonstrating the absurd constructs such an approach would imply.

However, it seems there is an alternate interpretation of viewupdates.  First, treat the INSERT statement above as a specification for a system of equations (set of constraints?) which must be uniquely solved for all variables in the database. Then, if a unique solution exists, execute some set of relational assignments which implement the solution; if no unique solution exists, return an error.

But I find this interretation to be equally problematic: what /is/ the system of equations for a given view-update? As far as I can tell, the system of equations specified by the INSERT amount to no more and no less than

  1. No database constraints are violated
  2. Subsequent queries against view V must return a relation value with member TUPLE {C1='Y'}.

Are there any additional requirements which must be satisfied? If not, then it is obvious that multiple solutions exist (and that multiple solutions will exist for any such system of equations). For instance, given the INSERT at hand, one solution might insert TUPLE {C1='Y'} into T and delete TUPLE {C1='X'} from T, while another solution might just insert TUPLE{C1='Y'} into T. Neither solution violates #1 nor #2 aobve, hence they are both valid solutions to the system of equations.

Am I missing something about the "view-updates-as-system-of-equations" interpretation? Received on Sun Aug 30 2009 - 22:08:42 CEST

Original text of this message