maria-developers team mailing list archive

[Nikita Malyavin <nikitamalyavin@xxxxxxxxx>]

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