From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Review of GetUserId() Usage |
Date: | 2014-09-25 20:34:06 |
Message-ID: | 20140925203406.GC16422@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Peter Eisentraut (peter_e(at)gmx(dot)net) wrote:
> On 9/24/14 4:58 PM, Stephen Frost wrote:
> > * Alvaro Herrera (alvherre(at)2ndquadrant(dot)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.
I agree.. We already have that distinction, through inherit vs.
noinherit. I don't think it makes sense to have it also for individual
commands which we feel "might not be as safe". You could still go
delete all their data w/o a set role if you wanted...
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-09-25 20:36:23 | Re: B-Tree support function number 3 (strxfrm() optimization) |
Previous Message | Simon Riggs | 2014-09-25 20:25:49 | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |