> On 31 Mar 2023, at 14:35, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Daniel Gustafsson <dan...@yesql.se> writes: >> Reading this section I agree that the mix of ok/danger in the same example >> can >> be tad misleading though. Something like the attached is what I would prefer >> as a reader. > > I think in your rewrite, "this query" is dangling a bit because there's > several sentences more before the query actually appears. I suggest > ordering things more like: > > expressions are evaluated. For example, > this query is dangerous because the > <literal>LIMIT</literal> is not guaranteed to be applied before the > locking > function is executed: > <screen> > SELECT pg_advisory_lock(id) FROM foo WHERE id > 12345 LIMIT 100; -- danger! > </screen> > This might cause some locks to be acquired > that the application was not expecting, and hence would fail to > ... > On the other hand, these queries are safe: > <screen> > SELECT pg_advisory_lock(id) FROM foo WHERE id = 12345; -- ok > ...
Yes, I like this version a lot better than what I proposed. > Separately from that: now that I look at this example, it's really > quite safe for any plausible plan shape. It used to be dangerous if > you had an ORDER BY, but there's no ORDER BY, and even if there were > we fixed that in 9118d03a8. Do we want to choose another example, and > if so what? The "not guaranteed" wording isn't really wrong, but an > example that doesn't do what we're saying it does isn't good either. Off the cuff I don't have any better suggestions, need to do some more thinking. -- Daniel Gustafsson
