On 1/1/19 3:18 AM, Andrew Gierth wrote:
> I had a comment around here which seems to have been lost:
>
> * Secondly, views (and explicit subqueries) currently have
> * different behaviour w.r.t. SELECT FOR UPDATE than CTEs do. A
> * FOR UPDATE clause is treated as extending into views and
> * subqueries, but not into CTEs. We preserve this distinction
> * by not trying to push rowmarks into the new subquery.
>
> This comment seems to me to be worth preserving (unless this behavior is
> changed). What I'm referring to is the following, which is unchanged by
> the patch:
>
> create table t1 as select 123 as a;
> create view v1 as select * from t1;
> select * from t1 for update; -- locks row in t1
> select * from t1 for update of t1; -- locks row in t1
> select * from v1 for update; -- locks row in t1
> select * from v1 for update of v1; -- locks row in t1
> select * from (select * from t1) s1 for update; -- locks row in t1
> select * from (select * from t1) s1 for update of s1; -- locks row in t1
> with c1 as (select * from t1)
> select * from c1 for update; -- does NOT lock anything at all
> with c1 as (select * from t1)
> select * from c1 for update of c1; -- parse-time error
>
> (Obviously, inlining decisions should not change what gets locked;
> the behavior here should not be changed unless it is changed for both
> inlined and non-inlined CTEs.)
I see, I misread the comment. I will re-add it, possibly with some word
smithing. Thanks!
Andreas
