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