Re: Overcoming SELECT ... FOR UPDATE permission restrictions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Overcoming SELECT ... FOR UPDATE permission restrictions
Дата
Msg-id 14383.1523933353@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Overcoming SELECT ... FOR UPDATE permission restrictions  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Proposal: Adding json logging