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
