Re: SUPPORT FOR DECLARATIVE TRANSITION CONSTRAINTS

On 20 sep, 14:15, Brian <br..._at_selzer-software.com> wrote:
> 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>- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

Yet within the update operations, you want matching of individual tuples using mechanisms that go beyond comparison of key values, to the effect that some database update that replaces a before state {t1 t2} with an after state of {t3 t4}:

• could be rejected by said mechanism if the transition happens to be t1->t3 / t2->t4
• but could be accepted by said mechanism if the transition happens to be t1->t4 / t2->t3

How can you possibly claim that such a mechanism would NOT be tuple-at- a-time ? Received on Mon Sep 20 2010 - 14:55:51 CEST