On 04/06/12 00:46, Ann Harrison wrote:
> On Mon, Mar 5, 2012 at 6:25 PM, Claudio Valderrama C. <[email protected]>
> wrote:
>
>> (Thorny issue, I hope Ann Harrison will comment.)
>>
>>
> And now, finally, a month later she does. Included after my signature is a
> bit of MySQL code which may explain my desire to keep things as simple as
> possible.
>
>
> Hello, currently the engine supports BLR4 (legacy) and BLR 5. All FB
>> versions generate BLR 5.
Sorry, but that's wrong. For Dialect1 BLR4 is generated.
if (dialect >
SQL_DIALECT_V5)
blr.add(blr_version5);
else
blr.add(blr_version4);
> My understanding and memory is that within a blr_rse, each stream has a
> context which is expressed as a single byte. My first reaction was to
> suggest adding a blr_rse2 using sixteen bit contexts. Obviously, even if
> that didn't trigger a BLR6 it would not be backward compatible, but there
> are other extensions to blr that haven't caused a version change and are
> also not backward compatible.
>
> Forward compatibility (i.e. the ability of a new engine to handle an old
> database) is critically important. If someone restores an old database, it
> may well have significant amounts of old blr in it. People really dislike
> a database that won't let them at their data - even if the data is old.
>
> Claudio has proposed increasing the blr version and changing those routines
> that manage blr to recognize that BLR4 and BLR5 have eight bit contexts but
> BLR6 has sixteen bit contexts. That's at least as clean as recognizing that
> blr_rse has eight bit contexts while blr_rse2 has sixteen bit contexts.
>
> What bothered me was the follow-on idea of fixing lots of housekeeping
> issues
>
>
>
>> Things we can do in the new BLR version:
>> - enlarge some values that are currently held in a single bit
>>
> Which means testing for blr version on every reference to them.
>
>
>> - allow for reuse of holes in the BLR namespace without risk of
>> misinterpreting a deprecated verb
>>
> Which means testing for blr version on every reference to them.
>
I agree here - not good. Currently we have to keep V4 flag in various
forms just to convert datetime_to_text() in different manner. Only if we
decide to have separate BLR6 parser...
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel