maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Aleksey!

On Feb 26, Aleksey Midenkov wrote:
> > > >
> > > > In other words, if one can create an arbitrary history by
> > > > manipulating @@timestamp variable,
> > > > @@system_versioning_insert_history allows to do it more
> > > > conveniently. But if one cannot - he cannot.
> > >
> > > Then do we need additional setting @@system_versioning_insert_history?
> > > Iff one can manipulate history via @@timestamp variable let him set
> > > row_start/row_end columns.
> >
> > Sure, that's possible.
> >
> > I just thought @@system_versioning_insert_history could be like an extra
> > safety (not security) measure. To prevent history from being modified
> > unintentionally.
> 
> Well, unless one specified row_start/row_end explicitly he is safe.
> 
> But, since we need to specify implicit system fields we cannot avoid
> adding one more session variable. In my current iteration I made
> @@force_fields_visible which is more straightforward in what it does:

I'm sorry, I don't understand.

First, visibility is pretty much unrelated concept. row_start/row_end
can be visible or invisible, and they can be writable or not writable -
those are orthogonal concepts.

And second, the name is wrong, there are no "fields" row_start and
row_end unless the user creates then explicitly. They are pieces of
metadata that every row has, something that Oracle, for example, calls
"pseudocolumns". Something like @@system_versioning_row_start_row_end_visible
would be more correct, but ugly. In fact, I'd say that
@@system_versioning_insert_history was the best one.

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx