Martijn van Oosterhout <kleptog@svana.org> writes:
>> there is actually no proof of the current order depency is really
>> a good idea. Other access lists work without that constraint.
> For something that may not be a good idea, it's awfully popular.
Didn't we have this entire discussion a month ago?
I don't think there would be any objection to adding a database-level
CONNECT privilege that's checked inside the database, *after* the
existing pg_hba.conf mechanism. That requires no new concepts: we
already have databases and privilege bits for them. If the default is
to grant CONNECT to PUBLIC then the behavior is backward-compatible, and
people can use the privilege, pg_hba.conf, or a combination to control
access. (Might be best to call it USAGE so we don't need to create a
new reserved word, but that's a minor detail.)
Eliminating pg_hba.conf altogether is a much harder sell, because you'd
have to prove that you're not giving up any functionality, and quite
frankly I don't think you can prove that. (Arguing that people don't
need the functionality you can't provide is not going to carry the day.)
In any case it would force a lot of relearning on DBAs, and there will
be push-back just because of that. I'm also not pleased with adding a
bunch of concepts that are not even part of the SQL world (eg, SSL,
Unix-domain connections) into GRANT.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
