On 06/27/2013 02:49 AM, Chris Farmiloe wrote: > So I would think that if this was to go further then "channels" would need > to be more of a first class citizen and created explicitly, with CREATE > CHANNEL, DROP CHANNEL etc: > > CREATE CHANNEL channame; > GRANT LISTEN ON CHANNEL channame TO rolename; > GRANT NOTIFY ON CHANNEL channame TO rolename; > LISTEN channame; -- OK > NOTIFY channame, 'hi'; -- OK > LISTEN xxxx; -- exception: no channel named "xxxx" > NOTIFY xxxx, 'hi'; -- exception: no channel named "xxxx" > > Personally I think explicitly creating channels would be beneficial; I have > hit issues where an typo in a channel name has caused a bug to go unnoticed > for a while. > ....But of course this would break backwards compatibility with the current > model (with implicit channel names) so unless we wanted to force everyone > to add "CREATE CHANNEL" statements during their upgrade then, maybe there > would need to be some kind of system to workaround this....
I agree, but that would make this a MUCH bigger patch than it is now. So the question is whether you're willing to go there. If nobody wants to work on that, I don't find it unreasonable to have some permissions on LISTEN/NOTIFY period. However, I'd like to see separate permissions on LISTEN and NOTIFY; I can easily imagine wanting to grant a user one without the other. Also, someone would need to do performance tests to see how much the permissions check affects performance. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
