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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
