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 secur...@mariadb.org _______________________________________________ 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
