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