On Wed, Oct 19, 2011 at 7:46 PM, Florian Pflug <f...@phlo.org> wrote: > On Oct20, 2011, at 01:19 , Tom Lane wrote: >> Florian Pflug <f...@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.
I didn't realize these dependencies weren't immutable. If that is the desired behavior, then I agree a warning should be sufficient to catch typo's and oversights. If you did want to make them immutable, I also like Florian's idea of a dependency graph. This would make the dumps less readable though. > > best regards, > Florian Pflug > > > -- > Sent via pgsql-hackers mailing list (email@example.com) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers