Currently, we disallow use of both FOR UPDATE and FOR SHARE in a single
query, as well as use of both NOWAIT and default "WAIT" semantics.
There is no reason for this except inadequately flexible data
representation, ie, a single flag for the whole Query instead of one per
target relation. I'm about to go fix that, because it looks to me like
the code will actually end up simpler as well as more flexible.
However, I notice that there is a definitional question this opens up:
what should happen given conflicting specifications for the same
relation? The obvious case is
FOR UPDATE OF x,y FOR SHARE OF y
but there is also the case of
FOR SHARE FOR UPDATE OF y
where the "FOR SHARE" implies all relations and therefore implicitly
conflicts with the per-relation FOR UPDATE flag on y.
Seems like we could adopt one of two attitudes: "throw an error"
or "use the more restrictive behavior" (the latter would make
FOR UPDATE win over FOR SHARE, and probably NOWAIT over WAIT).
In the case of the all-relations vs some-relations specs, we could also
try to make the all-relations spec apply only to the relations not
listed explicitly. But doing that seems a bit painful, particularly if
you want it to work independently of ordering of the clauses.
Another case to think about is that we consider FOR UPDATE/SHARE on a
view to mean that the clause propagates to all tables used in the view.
So if there's already any FOR UPDATE/SHARE specs inside the view
definition, "throw an error" would cause the query to fail unless
they're exactly like the clause applied to the view. (This is what
happens now, but it's not very nice IMHO.) "Use the more restrictive
behavior" seems like a more pleasant way to combine specs in this case.
I'm kind of leaning to "use the more restrictive behavior" but wanted
to ask if anyone really hates that.
regards, tom lane