Permission Model

Creating, updating, and deleting notifications all require an explicitly granted permission — grant it to whichever role(s) should be trusted to author notifications in your deployment, the same as for checks and thresholds. Direct inserts, updates, and deletes against the underlying notifications table are blocked outright for everyone else; reading it stays open (see Listing What's Registered).

Dispatching a notification — the internal step, run from inside the evaluation engine, that actually decides whether to fire and then does so — is not given elevated privileges, for the same reason the evaluation engine itself isn't (see The Access Model in the User Guide): it dynamically calls whatever function happens to be registered against a notification, which is data read out of a table, not a hardcoded call. Running that dispatch with elevated privileges would turn "was granted permission to create a notification somehow" into "can register a function that runs as the extension's owner." Whoever calls the evaluation engine needs their own privileges to actually run a 'function' notification's routine, exactly as they would to call that function directly.

In practice, this means anyone granted permission to create notifications should be treated as trusted with whatever privileges the role running the evaluation engine has. A 'function' notification's routine is created with permission to run granted to everyone by default, the same as any newly created PostgreSQL function, so it's directly callable by anyone unless you revoke that permission yourself. Creating a notification doesn't do this for you. See The Access Model in the User Guide for the full trust-model explanation, which applies identically to checks and custom evaluators.

Continue to Troubleshooting.