Permission Model

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

Dispatching an event — 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 an event, 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 an event 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'-type event's routine, exactly as they would to call that function directly.

In practice, this means anyone granted permission to create events should be treated as trusted with whatever privileges the role running the evaluation engine has. A 'function'-type event'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 an event 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.