=?UTF-8?B?VG9yc3RlbiBGw7ZydHNjaA==?= <torsten.foertsch@xxxxxxx> writes: > given a query like this: > select * > from account a > cross join lateral ( > select rate > from exchange > where target='USD' > and source=a.currency > order by date desc > limit 1) e > where a.id=19 > for update; > If I understand the documentation correctly, both rows, the one from > exchange and the one from account are locked, right? A look at the plan for this suggests that all rows returned by the sub-select will end up row-locked (whether or not they actually join to "a"). Note the LockRows node in the sub-select. > However, if I create a SQL function like this: [ no locking happens ] FOR UPDATE locking doesn't propagate into functions. For a moment I felt like this was a planner bug, but really it isn't: the locking would certainly not have propagated into a non-inlined function, so if the planner were to make it happen when inlining, that would make inlining change the semantics, which it should not. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
