Re: Overcoming SELECT ... FOR UPDATE permission restrictions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Overcoming SELECT ... FOR UPDATE permission restrictions
Date
Msg-id 14383.1523933353@sss.pgh.pa.us
Whole thread Raw
In response to Re: Overcoming SELECT ... FOR UPDATE permission restrictions  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.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


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Runtime Partition Pruning
Next
From: Michael Paquier
Date:
Subject: Re: Proposal: Adding json logging