Hello hackers,
SET my.username = 'tomas'
CREATE POLICY chat_policy ON chat
USING (current_setting('my.username') IN (message_from, message_to))
WITH CHECK (message_from = current_setting('my.username'))
This technique has enabled postgres sidecar services(PostgREST, PostGraphQL, etc) to keep the application security at the database level, which has worked great.
However, defining placeholders at the role level require superuser:
alter role myrole set my.username to 'tomas';
ERROR: permission denied to set parameter "my.username"
Which is inconsistent and surprising behavior. I think it doesn't make sense since you can already set them at the session or transaction level(SET LOCAL my.username = 'tomas'). Enabling this would allow sidecar services to store metadata scoped to its pertaining role.
I've attached a patch that removes this restriction. From my testing, this doesn't affect permission checking when an extension defines its custom GUC variables.
DefineCustomStringVariable("my.custom", NULL, NULL, &my_custom, NULL,
PGC_SUSET, ..);
Using PGC_SUSET or PGC_SIGHUP will fail accordingly. Also no tests fail when doing "make installcheck".
