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[]
Still this requires a revert of the memory context handling commit for load_hba() and load_ident(). I think you can get around the problem by changing these functions to work with CurrentMemoryContext and set it explicitly to the newly allocated PostmasterContext in PerformAuthentication(). In your function you could then create a temporary context to be discarded before leaving the function.
I still think you should not try to re-implement check_hba(), but extend this function with means to report line skip reasons as per your requirements. Having an optional callback function might be a good fit (a possible use case is logging the reasons line by line).