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
