maria-developers team mailing list archive
Mailing list archive
Re: MDEV-10035 DBUG_ASSERT on CREATE VIEW v1 AS SELECT * FROM t1 FOR UPDATE
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.
Chief Architect MariaDB