maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

Hi, Alexander!

On May 16, Alexander Barkov wrote:
> >
> >> Just now this parameter for VIEWs effectively (and silently) ignored. So
> >> error IMHO is better.
> >
> > It will break existing application where users have FOR UPDATE in the
> > view definition. But, probably, there won't be many?
> 
> I think there won't be many.
> For me it looks like when we added FOR UPDATE,
> we just forgot to disallow this in VIEW.
> 
> A more clear way is to use FOR UPDATE when invoking views than when 
> creating views:
> SELECT * FROM view1 FOR UPDATE;

That's different. See:

  CREATE VIEW v1 AS SELECT * FROM t1 FOR UPDATE;
  SELECT * FROM v1, t2;

This is different from

  SELECT * FROM t1, t2 FOR UPDATE;


the first locks only t1, the second - both t1 and t2.

> And by the way, it does not work even with TEMPTABLE. Here is an example:

Sure, I didn't say it does. I said it might work with TEMPTABLE and it
cannot possibly work with MERGE. Either we fix it to work or
we disallow it. 

> > But also this patch goes directly against the work that Bar is doing
> > now. This patch adds new manual syntax checks into the code, while
> > Bar is trying to have the grammar to allow only syntaxically corect
> > queries.
> 
> I even earlier made a patch disallowing this syntactically.
> It was in the previous letter. I'm attaching it again.
> 
> I made it before you commented in MDEV-10063 :)
> But then would not sent for review, because we had a discussing
> that it might be useful with TEMPTABLE...
> 
> But now when we know that TEMPTABLE does not really work...
> Ok to push the attached patch?

I think we need to apply the same logic to all per-SELECT clauses.
LOCK IN SHARE MODE, FOR UPDATE, HIGH_PRIORITY, STRAIGHT_JOIN,
SQL_SMALL_RESULT, SQL_BIG_RESULT, SQL_BUFFER_RESULT.

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx