Re: Overcoming SELECT ... FOR UPDATE permission restrictions

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> I also don't quite understand the argument of application relying on
> this behavior. If they do, that's wrong anyway, so the risk of
> operation disruptions for shared environments would matter more in my
> opinion.

I'm not totally sure about that. If you suppose that the only purpose
of doing SELECT FOR UPDATE is to clear the way for a subsequent UPDATE,
then people who are using it would certainly have had to grant the
necessary UPDATE permission to let the second command go through.
But I'm not 100% sure that that's the only use-case. S-F-U could be
useful strictly for mutual-exclusion perhaps. Or maybe your application
does S-F-U to get row locks, then does DELETE rather than UPDATE.

Still, it seems unlikely that somebody would be doing those sorts of
things through two levels of view. So maybe the set of applications
that would get broken is vanishingly small.

regards, tom lane