Hi, Sergei! That "double standard" is an obstacle for users to achieve maximum potential of software. Advanced users must know how internals work and because this is not documented it is frequently hard work. I'm just telling the downsides of the double concept. I know there are upsides of course: less documentation, smooth learning curve. But now and then developers make the dumbest from a user limiting his possibilities to a real frustration. I just want you to see my point and I feel like this happens every time with every software. On Thu, May 27, 2021 at 12:41 PM Sergei Golubchik <serg@mariadb.org> wrote:
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 security@mariadb.org
-- All the best, Aleksey Midenkov @midenok