Skip site navigation (1) Skip section navigation (2)

Re: control pg_hba.conf via SQL

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tino Wildenhain <tino(at)wildenhain(dot)de>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, BERTHOULE Emmanuel <pgdev(at)manberth(dot)homeip(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: control pg_hba.conf via SQL
Date: 2006-03-30 15:14:16
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> If your pg_hba.conf looks like
>> host	all	all	md5
>> there's not much call to update it dynamically ...

> There'll be a call to update it once - to ;-)

Doh ;-).  Should make more effort to check my throwaway examples ...

> But it's not clear to me why a CONNECT right shouldn't encompass all
> the things that hba does, i.e. connect method, source address and auth
> method.

Because that stuff doesn't fit into either the syntax of GRANT or the
system tables that store grant information.  It's talking about concepts
that don't even exist in the SQL world (while users and databases
certainly do).

Also, we know from experience that there's value in applying an ordered
set of tests in pg_hba.conf --- in particular, rules about "local" vs
"local net" vs "anywhere" connections are most easily expressed that
way.  We would need some substitute rule or concept in order to do the
same work in GRANT, and I don't see what that would be.

Recently in another thread someone was remarking about how ugly MySQL's
authentication methods are.  I think that's in part because they have
chosen to wedge the client hostname into their concept of user.  It doesn't
fit nicely.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: D'Arcy J.M. CainDate: 2006-03-30 15:15:21
Subject: Re: Slony-I for circular replication
Previous:From: Andrew DunstanDate: 2006-03-30 15:01:44
Subject: Re: control pg_hba.conf via SQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group