Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

From: Brian <brian_at_selzer-software.com>
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

Original text of this message