On 16.05.2016 14:56, Sergei Golubchik wrote:
Hi, Oleksandr!
On May 16, Oleksandr Byelkin wrote:
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. No, "FOR UPDATE" has no any traces in view.frm Yes, it doesn't work now. Above I meant, what the user expectations could be.
Yes, but they are against at least standard, and we should think a lot before implement yet another non-standard feature. The thing is theoretically doable, but require changes in current algorithm of processing. Also the question which setup overwrite which. Whole query derived table or vice versa.