Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS
Date: Mon, 20 Sep 2010 05:15:35 -0700 (PDT)
Message-ID: <22b3107e-d5b0-4449-82cf-f81860cb49f4_at_m1g2000vbh.googlegroups.com>
On Sep 20, 5:56 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 20 sep, 10:40, Brian <br..._at_selzer-software.com> wrote:
>
> > Is it so difficult to grasp that two different
> > propositions at different times can reference the same concrete
> > object?
>
> No, that is not difficult to grasp at all.
>
> It seems much more difficult for you to grasp that this is completely
> besides the point and completely irrelevant.
>
> > And by extension, is it so difficult to grasp that it should
> > be possible to match tuples in a relvar as it was prior to an update
> > to tuples in the database as it would be if the update were to
> > succeed?
>
> That may perhaps be possible.
>
> But once again, you seem to fail to realize that what you are
> advocating is precisely an update mechanism that operates at the tuple-
> level, and that that is in violation of the important prescription
> that all updates are set-level.
That is NOT what I'm advocating. The Tutorial D operation
UPDATE <relvar target> [WHERE <bool exp>] ( <attribute assign commalist> )
is set-based. DELETE and INSERT are set-based. The EXTEND relational algebra operator is set-based. Each of the additional relvar names I propose refers to sets of tuples, so constraints that employ them can use set-based relational operators.
<snip> Received on Mon Sep 20 2010 - 14:15:35 CEST