Re: Review of GetUserId() Usage

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Review of GetUserId() Usage
Дата
Msg-id 54245C53.8070906@gmx.net
обсуждение исходный текст
Ответ на Re: Review of GetUserId() Usage  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Review of GetUserId() Usage  (Stephen Frost <sfrost@snowman.net>)
Re: Review of GetUserId() Usage  (Stephen Frost <sfrost@snowman.net>)
Re: Review of GetUserId() Usage  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
On 9/24/14 4:58 PM, Stephen Frost wrote:
> Alvaro,
> 
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
>> I think the case for pgstat_get_backend_current_activity() and
>> pg_stat_get_activity and the other pgstatfuncs.c callers is easy to make
>> and seems acceptable to me; but I would leave pg_signal_backend out of
>> that discussion, because it has a potentially harmful side effect.  By
>> requiring SET ROLE you add an extra layer of protection against
>> mistakes.  (Hopefully, pg_signal_backend() is not a routine thing for
>> well-run systems, which means human intervention, and therefore the room
>> for error isn't insignificant.)
> 
> While I certainly understand where you're coming from, I don't really
> buy into it.  Yes, cancelling a query (the only thing normal users can
> do anyway- they can't terminate backends) could mean the loss of any
> in-progress work, but it's not like 'rm' and I don't see that it needs
> to require extra hoops for individuals to go through.

It would be weird if it were inconsistent: some things require role
membership, some things require SET ROLE.  Try explaining that.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Следующее
От: Tom Lane
Дата:
Сообщение: Re: jsonb format is pessimal for toast compression