Re: Allow file inclusion in pg_hba and pg_ident files

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Nathan Bossart <nathandbossart(at)gmail(dot)com>
Subject: Re: Allow file inclusion in pg_hba and pg_ident files
Date: 2022-10-26 15:32:14
Message-ID: 20221026153214.nx3lqcwoqclp7zbz@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, Oct 26, 2022 at 03:56:07PM +0900, Michael Paquier wrote:
> So, I have spent a good portion of today looking at what you have
> here, applying 0001 and 0003 while fixing, rebasing and testing the
> whole, discarding 0002 (we could do more for the line number and
> source file in terms of the LOGs reported for a regexec failure).


> Now remains 0004, which is the core of the proposal, and while it
> needs a rebase,

Have you already done a rebase while working on the patch or are you intending
to take care of it, or should I? Let's no both do the work :)

> - The TAP test, which is half the size of the patch in line number.
> Could it be possible to make it more edible, introducing a basic
> infrastructure to check a set of rules in pg_hba.conf and
> pg_ident.conf without the inclusion logic? Checks for error patterns
> (that I agree we strongly lack tests for) look like something we'd
> want to tackle independently of the inclusion logic, and it should be
> built on top of a basic test infra, at least.

I don't mind taking care of that, but before doing so I'd like to have some
feedback on whether you're ok with my approach (per my initial email about it
at [1]) or if you had some different
ideas on how to do it.


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2022-10-26 17:54:44 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Previous Message Egor Chindyaskin 2022-10-26 14:47:08 Re: Stack overflow issue