I think this would be great.

After all, it seems to me a bit inconsistent that indexes don't
really 'do' the generational thing, while everything else does. If
indexes could only see their own version, they'd be virtually
useless (or else exceptions would have to be raised on-commit, and
some way found of dealing with that without a full rollback).
Whatever, transaction-isolated indexes arn't really practical, even
though (to me) they seem more 'pure'.

So then, as Jerome suggests, shouldn't we have the option of letting
our triggers operate outside the local transaction (at lease for
selecting)?? Sure it would allow people to write stupid code if they
choose - but so does SELECT ... WITH LOCK

Triggers only. I can't at this moment see any use for this in a
sproc.

Something like; constraint-trigger: see everything; action-trigger:
see local transaction only.

John

--- In firebird-support@yahoogroups.com, "Jerome Bouvattier"
<JBouvattier@I...> wrote:

> Still, wouldn't it be interesting to have a way to flag a trigger

as running

> in the system context like declarative constraints would ?
> This would really help when you want integrity constraints that

can't be

> formulated with decl constraints or when you explicitly don't want

to use

> decl constraints (e.g you don't want to introduce a poorly

selective index).

> AFAIU, currently, writing custom constraints in triggers that

reads data

> outside the modified record isn't 100% safe since a trigger runs

in the

> client's transaction context (which could be in "snapshot" mode).