Rick,

I agree, I am just the messenger.

You wanted to know what was hapenning and why it was slow. I just
explained what it was internally doing. There are two schools of
thought on this.

1. I am doing this to avoid the spaghetti of if statements that I
would otherwise have to do. Code re-use is good, and if I can write a
single query that works in all cases (I mean returns the correct
results, not necessarily the most efficient way), then that is better
than re-writing the same query twice.

2. How much time should the optimiser spend correcting "stupid
queries". If a where clause is always true, then it shouldn't be
there. If it is always false, the query should not even be sent.

We are both in school 1, but I understand the thinking behind the
second. Hopefully in the future, Firebird will come up with a way of
handling this sort of query quick enough to not slow down the queries
sent by those in school 2. In the meantime however, you can build the
query at runtime inside a SP.

Adam

--- In firebird-support@yahoogroups.com, "Rick Debay" <rdebay@r...> wrote:
> We're not talking about optimizing a bizarre join, but a constant value.
> IMNSHO the optimizer should be able to check for constants.
> I've got queries like this, as a separate block of code for each
> possible condition would make the code unmanageable. Imagine if
> conditional statements in a given language could only have one logical
> statement, the resulting nested IF statements would be spaghetti.
>