Hi, Aleksey! On Apr 06, Aleksey Midenkov wrote:
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.
Sure, that's what @@system_versioning_insert_history would do.
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.
No, this is internal implementation detail that can change and it should not leak into the UI. Like, sql_select.cc has a function called sub_select(), but we never tell users that what it does is "subselect", not in the documentation, not in error messages, never. Because it doesn't (it performs one step in a nested-loop join). The fact that some internal enum value is named INVISIBLE_SYSTEM is not something that should affect the user visible behavior.
Besides, the variable is not about system versioning. It can make any system-invisible fields visible.
Which is incorrect. ROWNUM (MDEV-24089) is a pseudocolumn, and it cannot be "visible" in the sense of @force_fields_visible. We don't support ROWID, but if we would — it cannot be visible in the sense of @force_fields_visible either. Basically this variable can only apply to row_start/row_end pseudocolumns, despite its generic name. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org