Hi, Sergei! In short, I am on the side of standard conformance. Next two statements are generally out of scope of this bug, but: I like to see extra2 reading in separate function, and i believe that `TABLE_SHARE::init_from_binary_frm_image` needs more decomposiiton.
Further: > I don't quite like that a small and simple function dd_frm_type(), which > used to just read few first bytes of the frm file, gets more and more > complex, growing into a complete frm-open method. > > So, perhaps, I'd consider changing TRUNCATE to open the table properly > without all that just-read-few-bytes shortcuts. > Wasn't the there some performance issue as the reason to introduce such read-few-bytes thing? If it's not the case, then I'm okay with that, but feels like TRUNCATE code written in manner to make IO as fast as possible there. > Or, may be, simply document that TRUNCATE works on versioning tables > just as DROP+CREATE does. There is no logical reason why it shouldn't - > if one can do SHOW CREATE TABLE and CREATE OR REPLACE, then TRUNCATE > won't add any new functionality on top of that. That's the easiest and > most logical "fix" to this bug. Agree? > Consider we'll have VTMD someday at last. Then the TRUNCATE behavior will differ for different `vers_alter_history` modes. It is better to extend the command (or create new one) to make something related to versioning: either truncate only actual data, or only history (we already have delete history for this one), or both. Kind regards, Nikita Malyavin Tempesta Technologies tempesta-tech.com _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
