At 08:29 PM 6/4/2004, Jerome Bouvattier 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 ?

Interesting? Yes. But useful and reliable are way ahead of interesting
in my ordering of features.

>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).

At some point we need to disentangle indexes and foreign key constraints.
For reasons most unclear to me, the internals of the engine know that
there is an index where there is a foreign key. Having the creation
of a constraint build an index is OK, I guess, but the user should be
allowed to delete it.

What constraints can you not express in declarative language? As a
general rule, declarative constraints allow the engine more latitude
to choose the optimal execution method than procedural constraints.

>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).

That's right. And even if it were in inconsistent mode, you still
wouldn't see uncommitted changes.


Regards,


Ann