maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

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



-- 
All the best,

Aleksey Midenkov
@midenok