Mark Dilger <mark.dilger@enterprisedb.com> writes:
> Your proposal to just punt on supporting revocation of set on userset from public seems fine. We could revisit that
inthe next development cycle if anyone really wants to defend it. In particular, I don't see that committing this
featurewithout that part would create any additional backward compatibility problems when implementing that later.
Yeah. Also, as you noted, we could mark some individual built-in
variables as SUSET and add a default GRANT. I don't want to do that with
a blunderbuss, but perhaps there's an argument to do it for specific
cases (search_path comes to mind, though the performance cost could be
significant, since I think setting that in function SET clauses is
common).
For now, though, saying that you can't restrict SET for USERSET variables
seems fine --- there's certainly no loss of capability compared to where
we stand today. I'd prefer to get the feature committed in that form
and then look at whether we want to tighten things around the margins.
regards, tom lane