Re: ASYNC Privileges proposal
От | Craig Ringer |
---|---|
Тема | Re: ASYNC Privileges proposal |
Дата | |
Msg-id | 519A1122.5090100@2ndquadrant.com обсуждение исходный текст |
Ответ на | ASYNC Privileges proposal (Chris Farmiloe <chrisfarms@gmail.com>) |
Список | pgsql-hackers |
On 05/20/2013 09:54 AM, Chris Farmiloe wrote: > Hey all, > > I find the current LISTEN / NOTIFY rather limited in the context of > databases with multiple roles. As it stands it is not possible to restrict > the use of LISTEN or NOTIFY to specific roles, and therefore notifications > (and their payloads) cannot really be trusted as coming from any particular > source. Just for context, here's the dba.stackexchange.com question where this was previously raised: http://dba.stackexchange.com/q/42496/7788 I agree that this only became relevant since NOTIFY payload support was added, so we can't really just say "nobody's wanted this in 15 years". A couple of years, maybe, but given the lagging client driver support for NOTIFY payloads, maybe not even that. That said, I personally don't see this as a significant problem since the approach that worked prior to the introduction of notify payloads - just using a staging table - continues to work just fine. I agree with Tom that much finer grained control would be required if adding privileges at all were to be particularly useful; such a coarse right as Chris proposes seems unlikely to cover many use cases. We'd likely control over who can NOTIFY and who can LISTEN to a given channel name. I'm just not convinced it's worth the complexity it'll introduce or any performance consequences. If it could be done by adding a few hooks that a C extension could use, that might be worthwhile though. The same argument might be applied to advisory locking, after all. I can't really see adding fine-grained rights to _everything_, but hooks might not be harmful. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: