On Oct20, 2011, at 01:19 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> Taking this even further, why do we bother with non-immutable (i.e.,
>> depending on the database's contents) checks during ALTER ROLE/DATABASET SET
>> at all?
>
> Yeah, I was wondering about that one too. It would not solve all the
> problems here, but skipping validity checks would fix some of them.
> The trouble of course is what happens if the value is found to be bad
> when you try to use it ...
Presumably we'd detect that during logon, because the GUC assignment
hook will quite probably complain. I'd vote for emitting a warning in
that case. This is also what we due currently if we fail to set the
GUC to the desired value due to permission issues
postgres=# create role r1 login;
CREATE ROLE
postgres=# create role r2;
CREATE ROLE
postgres=# alter role r1 set role = r2;
ALTER ROLE
postgres=# \connect - r1
WARNING: permission denied to set role "r2"
WARNING: permission denied to set role "r2"
You are now connected to database "postgres" as user "r1".
(Dunno why that WARNING appears twice)
Since an ALTER DATABASE/ROLE SET doesn't prevent the user from overriding
the value, ignoring invalid settings shouldn't be a security risk.
best regards,
Florian Pflug