maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Aleksey!

Wow, this comes so late, sorry! :(

But it's fixVersion=10.6 and on the top my list, so here you are.

On May 07, Aleksey Midenkov wrote:
> >
> > The conclusion, I believe, is that system_versioning_modify_history
> > should allow INSERTs when secure_timestamp=NO, and it should allow
> > UPDATE/DELETE only for a SUPER user when secure_timestamp=NO or SUPER.
> 
> I don't see a reason to argue on that. The only thing that is not
> clear, why we don't allow INSERTs when secure_timestamp=SUPER?

Sure, I meant back then that INSERT/UPDATE/DELETE would be allowed when
secure_timestamp=SUPER.

But now I think we shouldn't really allow UPDATE/DELETE at all.

I wrote earlier that "Now, with a SUPER privilege and
secure_timestamp=NO or SUPER, one can use the BINLOG command and truly
edit the history arbitrarily, by faking row events."

Which is true, but we want to change it.
In https://jira.mariadb.org/browse/MDEV-18432.

So, it's looks reasonable to allow only INSERTs - they can fake new
history, which is needed for mysqldump, but at least there will be no
command to selectively delete or modify history.

> > The second thing I don't like at all, is when a table is created like
> >
> >   CREATE TABLE t1 (a int) WITH SYSTEM VERSIONING
> >
> > with row_start/row_end implicit. You don't have it in the test, but
> > anyway one should be able to load history into such a table, while
> > the table does not have row_start and row_end columns. From the user
> > point of view these columns don't exist, they're pseudo-columns,
> > like ROWID. They just cannot be insertable-into, conceptually. But a
> > user will want to restore the history, right? I don't have a
> > solution for this yet :( Any ideas?
> 
> We don't have to follow the conception if it doesn't help us. Since we
> have physical row_start/row_end, we don't have to pretend they don't
> exist. Who will win from that?

Yes, you're right.

Then for the purpose of mysqldump they should be insertable-into. And
mysqldump should only care to list them explicitly in the column list,
like with any other insivible columns. This looks easy.

Regards,
Sergei
VP of MariaDB Server Engineering
and security@xxxxxxxxxxx