At 10:15 AM 5/7/01 -0400, Leyne, Sean wrote:

>
>Since the SQL would have already been parsed in order to determine which
>tables are being accessed, how do you propose to allow for the trigger
>to change the parsed statement?
>

Yes. The minimum functionality is for the trigger to be able to
add an arbitrary conjunct to the selection expression.

>How would you see the trigger parsing through the SQL statement to
>determine how to add the "where" clause?
>

A context object passed to the trigger would expose an API that
suppored generation of the conjunct. Design of the API is important
down the road, but not now.

Current Firebird triggers probably don't have the computational
power to implement this type of a feature. Java based triggers
would. Whether it made more sense to beef up the existing trigger
language or accelerate Java triggers is also an issue that can
be deferred.

>In the case of multi-table joins, would the trigger be called for each
>table? In the case where two tables have runtime client restrictions,
>wouldn't adding the criteria for both tables result in a needlessly slow
>statement execution.
>

Since the trigger is defined per table (a question worth discussing),
yes. And for reflexive joins, also yes.

>What about situations where a client "where" clause has already been
>added to the statement, wouldn't adding a second occurrence, needlessly
>slow the statement execution.
>

Duplicate booleans could be removed by the optimizer, but even without
that, the cost of a redundant conjunct is minimal. The more important
question is how to make additional selection criteria available before
optimization.

Jim Starkey