Haribabu Kommi <kommi.harib...@gmail.com> writes:
> On Sat, Apr 9, 2016 at 6:36 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> More generally, I'm not convinced about the use-case for this patch.
>> What problem is it supposed to help in dealing with, exactly? Not syntax
>> errors in the hba file, evidently, since it doesn't make any attempt to
>> instrument the file parser. And it's not very clear that it'll help
>> with "I can't connect", either, because if you can't connect you're
>> not going to be running this function.
> Apologies for replying an old thread.
> The main reason behind of this patch is for the administrators to control
> and verify the authentication mechanism that was deployed for several
> users in the database is correctly picking the assigned hba config or not?
That doesn't really answer my question: what is a concrete use-case for
this function? Reproducing the same behavior that would happen during
a login attempt does not seem terribly useful from here, because you
could simply attempt to log in, instead. As I said upthread, maybe we
need a bit more logging in the authentication logic, but that doesn't
seem to lead to wanting a SQL function.
What I actually think we could use is something like the pg_file_settings
view, but for pg_hba.conf. In particular, pg_file_settings has a specific
charter of being able to detect syntax errors in not-yet-loaded config
files. That seems like clearly useful functionality to me, but we don't
have it for pg_hba.conf (and this patch didn't add it).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
