On 04/06/12 00:46, Ann Harrison wrote:
> On Mon, Mar 5, 2012 at 6:25 PM, Claudio Valderrama C. <cva...@usa.net>
>  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

Reply via email to