Hi, Aleksey! On Apr 27, Aleksey Midenkov wrote: > > On Apr 06, Aleksey Midenkov wrote:
> > > 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. > > That's not about permission of inserting history which can be > controlled by @@secure_timestamp setting. But rather that's about > allowing to put system-invisible fields into INSERT command. You can > suggest a better name for it. yes, @@system_versioning_insert_history is not @@system_versioning_allow_permissisions_to_insert_history. So it's not about permissions, it's about "insert history [rows]" - with everything that's needed. > > 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). > > Every concept should have a proper application. I don't think "double > design" in hiding system versioning fields adds any value. I can not > be sure about "subselect" design, but I suspect it will never be > replaced by anything else. In any case each and every solution should > be judged by whether it adds usability (i.e. ease of use) or not. Yes, and the intended and documented behavior, that you've implemented, is - either a user specifies row start/end fields explicitly, as the standard requires, and they exist as normal fields - or the user doesn't, and they don't. The internal implementation specifics don't necessarily have to leak into UI. For example, SEQUENCE objects - they are separate objects in the standard and mostly behave as such in MariaDB too. But internally they're implemented as some special kind of a table. Stored routines are also a completely separate kind of objects. Despite the fact that we store them as rows in mysql.proc table. So, if a user hasn't created row start/end columns - there are no row start/end columns. The server stores this information _somewhere_ and makes it available in SELECT queries as pseudocolumns. With @@system_versioning_insert_history these pseudocolumns are allowed in INSERT too. 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