On 10/14/10 11:50, Dmitry Yemanov wrote:

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

Yes. I just do not want to create such problems from nothing. I
understand very well why we needed OldParameterOrdering (to have new
correct ordering in normal cases) and OldColumnNaming (to be normally
standard compliant). But what do we achieve normally disabling use
non-cursor fetch? For people who use API with care about roundtrips, we
add nothing - they anyway do not fetch from such statements. Certainly,
if after disabling such fetches we have serious code simplification - I
can agree with that change.

>> 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 remember something like sort by blobs, when actually blob id's were
sorted. We had to turn it on again:-)

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

It seems that good solution can be keeping old API as is, but in the
planned new one have correct (error without output SQLDA / message)
behavior.

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

Provided we anyway have 2.5.0 released with such fetches turned off,
let's wait and see, what will people say.