Hi Sergei, On Mon, Apr 5, 2021 at 8:04 PM Sergei Golubchik <serg@mariadb.org> wrote:
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.
To be able to specify them in INSERT command they must be at least user-invisible. System-invisible fields are ignored.
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.
I think you are complicating things where complication is not needed. Pseudo- or not they are fields. Besides, the variable is not about system versioning. It can make any system-invisible fields visible.
Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org
-- All the best, Aleksey Midenkov @midenok