Re: Review of GetUserId() Usage

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Review of GetUserId() Usage
Дата
Msg-id 20141016134908.GA28859@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Review of GetUserId() Usage  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Review of GetUserId() Usage
Список pgsql-hackers
* Peter Eisentraut (peter_e@gmx.net) wrote:
> On 9/24/14 4:58 PM, Stephen Frost wrote:
> > * 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.

Agreed.

As a side-note, this change is included in the 'role attributes' patch.

Might be worth splitting out if there is interest in back-patching this,
but as it's a behavior change, my thinking was that it wouldn't make
sense to back-patch.
Thanks,
    Stephen

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: UPSERT wiki page, and SQL MERGE syntax
Следующее
От: Nick Barnes
Дата:
Сообщение: Question about RI checks