On Thu, Feb 1, 2018 at 8:09 PM, Tatsuo Ishii <is...@sraoss.co.jp> wrote: > Initially I thought all base tables including ones in a subquery also > should be locked like you. But after some discussions with Yugo, I > agree that locking table in a subquery is less valuable for users (and > I am afraid it may introduce more deadlock chances). See upthead > discussions.
I just reread those discussions but I don't see that they really make any argument for the behavior the patch implements. I see no explanation on the thread for why locking a table inside of a subquery is more or less likely to cause deadlock than locking one outside of a subquery. >> I think that if we >> change the rules for which subqueries get flattened in a future >> release, then the behavior will also change. That seems bad. > > I doubt it could happen in the future but if that happend we should > disallow locking on such views. That doesn't make any sense to me. When someone migrates from PostgreSQL 11 to, say, PostgreSQL 14, the view definition is going to be recreated from an SQL query. Neither the user nor the database will know whether the query was optimized the same way on both databases, so how could we disallow locking only those views where there was a difference on the two releases? Even if we could, how does that help anything? Throwing an error is just as much a backward-incompatibility in the command as silently changing what gets locked. But my complaint may have been a little off base all the same -- I guess we're doing this based on the rewriter output, rather than the optimizer output, which makes it a lot less likely that we would decide to change anything here. >> I also think that this is a bad idea for another reason, which is that >> it leaves us with no syntax to say that you want to lock the view >> itself, and pg_dump wants do that if only we had syntax for it. > > I agree with Yugo and Alvaro. It's better to have a separate syntax > for locking views itself. > > https://www.postgresql.org/message-id/20171226143407.6wjzjn42pt54qskm@alvherre.pgsql Hmm, Alvaro's argument makes sense, I guess. I withdraw this complaint. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
