> Being sensitive to
> the order of AND operands in an expression, not pre-evaluating
> constant expressions and so forth are just shortcomings of the
> optimizer, whatever side you turn it,

This I would agree with.

The failure of an optimiser to realise that a constant expression does
not need to be evaluated for every record in a table is an optimiser
limitation.

However on a practical level, those goal posts can by definition
*never* be fixed. There is limited resources in every project (open
source or otherwise), so work on the optimiser to let it recognise
these sorts of tricks means that work in some other area must wait. I
am sure the Firebird project could spend the rest of its days simply
adjusting the optimiser to cope with every unusual query it doesn't
currently handle well.

Most automatic query generators are smart enough to not insert dummy
constant expressions, the one you are using must not be. The fact it
isn't as usual a situation as you may imagine goes a long way to
explain why you haven't seen developers jumping out of their skin to
implement it.

Another approach that you can use if your primary keys are generator
based is as follows:

ID > 0 is logically equivalent to 1=1
ID < 0 is logically equivalent to 1=0

We used this approach at one stage in part of our product and it
worked well.

Good luck.

Adam