Re: Parsing of pg_hba.conf and authentication inconsistencies

Stephen Frost wrote:
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> Tom Lane wrote:
>>> It isn't, and I seem to recall we've had that scenario play out a couple
>>> times already for postgresql.conf changes. But pg_hba.conf is far more
>>> complex than "variable = value" ...
>> Ok, then I didn't misunderstand that part at least :-)
>>
>> Ah, well. I know that if others don't pipe in on my side of it, I'm
>> implicitly out-voted ;), since I've stated my case by now... Thus, I
>> won't put any time into working on it unless someone does.
>
> Having one doesn't imply we don't have the other. I believe we should
> definitely have both the --check-config (to address Tom's concern, and
> to improve the user experience when doing an /etc/init.d/postgresql
> reload or similar) and the check done in the postmaster and have it only
> update the running config if the config file parsed correctly.

I thought of another issue with this. My "grand plan" includes being
able to do username mapping (per pg_ident.conf) for other authentication
methods than ident. Specifically this would be interesting for all
external methods, like gssapi/sspi/kerberos/ldap. I was originally
planning to allow each row in pg_hba to specify it's own pg_ident.conf
if necessary (so you could map LDAP and GSSAPI differently, for example,
or map two different kerberos realms differently). To be able to load
these, the postmaster would need to know about them, which means it'd
have to parse that data out anyway.

The other way to do that is to simply say that all external mapping will
use pg_ident.conf, and the only thing you can specify on a per-row basis
is "use map: yes or no". This decreases the flexibility, but would not
require the postmaster to do the parsing.

What do people think about these? I know Stephen for example really want
that feature so - would that restriction make it a lot less useful for you?

//Magnus