maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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@xxxxxxxxxxx