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@mariadb.org