Re: Allow file inclusion in pg_hba and pg_ident files

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Julien Rouhaud <rjuju123(at)gmail(dot)com>
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 06:56:07
Message-ID: Y1jaB6bYPvxvPL4t@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 26, 2022 at 11:19:48AM +0800, Julien Rouhaud wrote:
> That wouldn't be overdoing anymore if we remove the line number / filename from
> the fill_*_line prototypes right?

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, I have not been able to spend much time looking at its
internals. In order to help with the follow-up steps, I have spotted
a few areas that could be done first:
- The diffs in guc.h/c for the introduction of GetDirConfFiles() to
get a set of files in a directory (got to think a bit more about
ParseConfigFp() when it comes to the keywords, but that comes to play
with the parsing logic which is different).
- 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.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-10-26 07:18:47 Re: Some regression tests for the pg_control_*() functions
Previous Message Bharath Rupireddy 2022-10-26 06:06:17 Re: Move backup-related code to xlogbackup.c/.h