Re: pg_hba_lookup function to get all matching pg_hba.conf entries - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: pg_hba_lookup function to get all matching pg_hba.conf entries
Date
Msg-id CAJrrPGeTObQ3nTrb_-=SXd+W67NzpFiqdAt6z10jGTDZa0Zaqw@mail.gmail.com
Whole thread Raw
In response to Re: pg_hba_lookup function to get all matching pg_hba.conf entries  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_hba_lookup function to get all matching pg_hba.conf entries  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
List pgsql-hackers
On Thu, Dec 24, 2015 at 2:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de> writes:
>> 1. Have you considered re-loading the HBA file upon call to this function
>> in a local context instead of keeping it in the backends memory?
>
> Aside from the security questions, please consider that this feature should
> work similarly to the current implementation of the pg_file_settings view,
> namely it tells you about what is *currently* in the on-disk files, not
> necessarily what is the active setting in the postmaster's memory.
> A backend could not be entirely sure about the postmaster's state anyway;
> and even if it could be, one of the major applications for features like
> this is testing manual changes to the files before you SIGHUP the
> postmaster.  So re-reading the files on each usage is a Good Thing, IMO,
> even if it sounds inefficient.
>
>> 2. I also wonder why JSONB arrays for database/user instead of TEXT[]?
>
> Yes, that seems rather random to me too.

Here I attached updated patch with the following changes,
- Local loading of HBA file to show the authentication data
- Changed database and user types are text[]

Regards,
Hari Babu
Fujitsu Australia

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Additional role attributes && superuser review
Next
From: David Rowley
Date:
Subject: Re: PATCH: use foreign keys to improve join estimates v1