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