Re: Regrading TODO item alerting pg_hba.conf from SQL

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 :)