On Sun, 2006-04-16 at 11:48 -0400, Tom Lane wrote:
> 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.)
Tom, could you please provide more insight of how you see this taking
shape. I am sure your vote counts heavy on this. How would you suggest
the SQL syntax be like for example.
> 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.
>
Of course, there are many legitimate reasons why the existing
pg_hba.conf should be left alone. There is no arguing in that. I just
wanted to make sure where the sirs stand :)