Subject | Re: [Firebird-Architect] ORs in Where statement |
---|---|
Author | Mark O'Donohue |
Post date | 2003-06-14T00:27:02Z |
HI Jim
Jim Starkey wrote:
to have a runtime option for 1.5 to give backward compatibility if
needed, and to remove it completely in 2.0.
From a users perspective sometimes it's nice to have a cop out clause
when something unexpected goes wrong when upgrading.
For instance a runtime option would have helped in 1.0.1 when duplicate
field references became an error, rather than have to release an
emergency patch for ibobjects for instance (or iboconsole), it would
have given Jason (and Lorenzo) a bit of grace time to fix the problem in
a more ordered release scheme of their own products.
I don't think it's worth mangling the code to try and do this in every
instance, but certainly where it's easy to do, and the impact of the
change is uncertain, it can help.
Otherwise certainly for architectual simplicity and consistancy, I
strongly agree, it's best this feature is removed in 1.6 (or 2.0 if
thats what next).
Cheers
Mark
Jim Starkey wrote:
> The current Firebird implementation of complete evaluation of booleanBasically I agree with you but I think it's reasonable in certain cases
> sub-expressions is the result of an error of reasoning; it does not
> provide the benefit intended. It should be eliminated from product
> and not retained as a build, installation, or configuration option.
>
>
to have a runtime option for 1.5 to give backward compatibility if
needed, and to remove it completely in 2.0.
From a users perspective sometimes it's nice to have a cop out clause
when something unexpected goes wrong when upgrading.
For instance a runtime option would have helped in 1.0.1 when duplicate
field references became an error, rather than have to release an
emergency patch for ibobjects for instance (or iboconsole), it would
have given Jason (and Lorenzo) a bit of grace time to fix the problem in
a more ordered release scheme of their own products.
I don't think it's worth mangling the code to try and do this in every
instance, but certainly where it's easy to do, and the impact of the
change is uncertain, it can help.
Otherwise certainly for architectual simplicity and consistancy, I
strongly agree, it's best this feature is removed in 1.6 (or 2.0 if
thats what next).
Cheers
Mark