14.10.2010 11:19, Alex Peshkoff wrote:

>
> Is it only me with strong feeling of deja vu?
> Look at this configuration parameters: OldParameterOrdering and
> OldColumnNaming. I'm sure that if we break compatibility with old
> documented behavior, quite soon we will have to have OldNonCursorFetch
> in firebird.conf.

It depends on how many users would be affected. So far I don't know of
any commonly used connectivity library that uses the disabled approach.

And note that we tend to deprecate (and further remove) those backward
compatibility configuration options in new releases, so it's not an
absolute evil ;-)

> I can agree with breaking legacy behavior only when such break is
> required to fix some other, more dangerous bug (like security one).

Or when the old behavior is agreed to be plain wrong. We have enough
examples in our history in this regard.

> I did not understand, what was the reason to break legacy behavior in
> 2.5. If it was only in order to fix foolish incompletely-documented old
> API, I suggest to rollback this change. I can imagine how many legacy
> software will suffer from it.

Speaking honestly, it looks like an incidental change. Or at least the
details posted in my message weren't known and the change looked correct
at the first glance.

But getting back to the wrong (or just bad) behavior is not a good long
term solution, IMHO. So I'd want to see something better in v3.0. This
is why I'm asking what should we choose: fix the problems in the old
code keeping its supposedly illogical nature or change the behavior,
even if this would mean problems with backward compatibility.

As for the shorter term, I have no major objections against rolling this
change back in v2.5.1, but only if there will be more users affected.
Otherwise, we either keep the current logic or backport the complete
solution from the trunk once it's done.


Dmitry