* Tom Lane (t...@sss.pgh.pa.us) wrote: > IIRC, we do have mechanism now whereby a superuser can establish settings > for SUSET variables via ALTER ROLE SET/ALTER DATABASE SET, and > everything works as expected.
I'm not entirely convinced that it works as expected, at least for
temp_tablespaces currently. This was a bit surprising to me:
=# alter user test_role set temp_tablespaces='zz';
NOTICE: tablespace "zz" does not exist
ALTER ROLE
=*# commit;
COMMIT
=# set role test_role;
SET
=*> show temp_tablespaces;
temp_tablespaces
------------------
rn_temp_01
(1 row)
> So the only loss of flexibility here
> would be if you want unprivileged code to be able to set
> temp_tablespaces for itself.
I'm on the fence about this one. I could see that being useful in some
cases when there are a lot of temporary tables being created and you
need more than one tablespace for simple space reasons. It'd be
unfortuante if you had to be a superuser and/or call a superuser
security definer function to handle that situation.
> However, if you want that then it's hard
> to argue that there shouldn't be a permissions check, and then we're
> back into the surprises mentioned previously.
I'm not sure we're going to be able to get away from that.
> It might be possible to compromise on an arrangement whereby tablespace
> permissions checking only occurs if the active value of the variable was
> set by a non-superuser. But TBH that idea fills me with dread --- we
> don't have any other GUCs that work like that, and it seems too likely
> that there would be conceptual or implementation bugs in it.
I don't particularly like that either.
Thanks,
Stephen
signature.asc
Description: Digital signature
