Re: MERGE as the imperative form of aggregation

Marshall wrote:

> On Apr 16, 10:24 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>

>>Marshall wrote:
>>
>>
>>>So that's what got me to thinking about trying to make a
>>>closer correspondence between the imperative and algebraic
>>>operators. I have to say I find the idea appealing.
>>
>>If one has assignment and if one has the algebraic operators, what does
>>one lack?

Not necessarily.

  The context-free
> evaluation of (2) will transfer one row from client to server.

In (1), the server already has T -- all it needs is row. The question is can we devise an optimizer that recognizes such.

> If we reluctantly abandon context-free expression evaluation,
> we now have to either 1) come up with a theoretic framework
> that can transform any assignment into a comparably efficient
> set of operations under the covers, using some hidden imperative
> operators that will probably look a lot like insert, delete and
> maybe update, or else 2) accept some hideous network
> inefficiencies. I don't know how to do 1) and I don't want to do 2).
>
> Alternatively, we could just directly support insert/delete/whatever
> in the kernel language. This seems the better choice.

Why do you think the operators must be hidden? If (1) and (2) are equivalent, presumably one can devise a constructive proof of such, which means one can devise a method to convert between them.

> Certainly assignment is a very clean way to describe the
> abstract semantics of any imperative operators one cares
> to define. However that alone is not sufficient reason to
> include or even allow it in the concrete kernel language.
> If one was not thinking in terms of distributed computing,
> this consideration would not apply. However my interests
> include distributed operation.

I suggest distributed computing requires distributed optimization too.

>>>>Next, there are insert, update, and delete triggers. Now merge is
>>>>expected to be combination of insert, update; naturally insert and
>>>>update triggers are expected to be fired when issuing a merge
>>>>statement?
>>
>>>Triggers, sigh. I have a poor grasp of what they are for and
>>>what they mean from a theoretical standpoint. What are they
>>>necessary for?
>>
>>Very little. Something like them may be required to resolve
>>ambiguity in view updates.

IMO, the early introduction of stored procedures retarded the development of several dbmses. Instead of fixing problems in the engine and the optimizer, vendors tended to offer stored procedure hacks to work around the problems.

I prefer to see a coupled language where the issue of whether the code is on the client or the server becomes irrelevant.

>>>  I have seen good descriptions of how to
>>>express view updating as triggers that model the inverse
>>>view, but would that be necessary if we had full view updating
>>>in the engine?
>>
>>I suppose that depends on what you mean by "full view updating". It
>>strikes me that some view updates are ambiguous. How does "full view
>>updating" resolve the ambiguity?

I favor clarity over cleverness. How clear would it be?

>>>  What are triggers necessary for? I am clear
>>>on the value of *notification* of changes being sent to other
>>>components, but *actions* are less clear to me. Especially
>>>"instead of" actions.
>>
>>Triggers can automate the correct method for preserving invariants under
>>certain transformations. For example, one may decide to present some
>>group of users with an interface that allows them to simply delete any
>>invoice from their view regardless of the constraints and even without
>>deleting any tuples in base relations.