Show inline comments from pg_hba lines in the pg_hba_file_rules view
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t48385psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 12:12 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t48385_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t48385_1 && git checkout t48385_1Patchset v1 (message #1) is on t48385_1
Hi,
Often we make changes in the pg_hba.conf and leave a #comment there,
just in case we forget why the change was done. To avoid having to open
the configuration file every time just to check the comments, it would
be quite nice to have the option to read these comments in the
pg_hba_file_rules view. Something like adding it in the end of the line
and wrapping it with characters like "", '', {}, [], etc
For instance, this pg_hba.conf ...
# TYPE DATABASE USER ADDRESS METHOD
local all all trust [foo]
host all all 127.0.0.1/32 trust
host all all ::1/128 trust [bar]
local replication all trust
host replication all 127.0.0.1/32 trust
hostssl replication all ::1/128 cert map=abc [this will
fail :)]
... could be displayed like this
postgres=# SELECT type, database, user_name, address, comment, error
FROM pg_hba_file_rules ;
type | database | user_name | address | comment | error
---------+---------------+-----------+-----------+-------------------+-----------------------------------------------------
local | {all} | {all} | | foo |
host | {all} | {all} | 127.0.0.1 | |
host | {all} | {all} | ::1 | bar |
local | {replication} | {all} | | |
host | {replication} | {all} | 127.0.0.1 | |
hostssl | {replication} | {all} | ::1 | this will fail :) |
hostssl record cannot match because SSL is disabled
(6 rows)
I wrote a very quick&dirty PoC (attached) but before going any further I
would like to ask if there is a better way to read these comments using
SQL - or if it makes sense at all ;-)
Any feedback is much appreciated. Thanks!
Jim
On Fri, Sep 01, 2023 at 12:01:37AM +0200, Jim Jones wrote:
Often we make changes in the pg_hba.conf and leave a #comment there, just in
case we forget why the change was done. To avoid having to open the
configuration file every time just to check the comments, it would be quite
nice to have the option to read these comments in the pg_hba_file_rules
view. Something like adding it in the end of the line and wrapping it with
characters like "", '', {}, [], etcFor instance, this pg_hba.conf ...
# TYPE DATABASE USER ADDRESS METHOD
local all all trust [foo]
host all all 127.0.0.1/32 trust
host all all ::1/128 trust [bar]
local replication all trust
host replication all 127.0.0.1/32 trust
hostssl replication all ::1/128 cert map=abc [this will fail
:)]... could be displayed like this
hba.c is complex enough these days (inclusion logic, tokenization of
the items) that I am not in favor of touching its code paths for
anything like that. This is not something that can apply only to
pg_hba.conf, but to all configuration files. And this touches in
adding support for a second type of comment format. This is one of
these areas where we may want a smarter version of pg_read_file that
returns a SRF for (line_number, line_contents) of a file read? Note
that it is possible to add comments at the end of a HBA entry already,
like:
local all all trust # My comment, and this is a correct HBA entry.
--
Michael
Hi Michael
On 01.09.23 03:18, Michael Paquier wrote:
hba.c is complex enough these days (inclusion logic, tokenization of
the items) that I am not in favor of touching its code paths for
anything like that. This is not something that can apply only to
pg_hba.conf, but to all configuration files.
It is indeed possible to extrapolate it to any configuration file, but
my point was rather to visualize comments purposefully left by the DBA
regarding user access (pg_hba and pg_ident).
And this touches in
adding support for a second type of comment format. This is one of
these areas where we may want a smarter version of pg_read_file that
returns a SRF for (line_number, line_contents) of a file read? Note
that it is possible to add comments at the end of a HBA entry already,
like:
local all all trust # My comment, and this is a correct HBA entry.
I also considered parsing the inline #comments - actually it was my
first idea - but I thought it would leave no option to make an inline
comment without populating pg_hba_file_rules. But I guess in this case
one could always write the comment in the line above :)
Would you be in favor of parsing #comments instead? Given that # is
currently already being parsed (ignored), it shouldn't add too much
complexity to the code.
Thanks for the feedback.
Jim
On Fri, Sep 01, 2023 at 11:32:35AM +0200, Jim Jones wrote:
Would you be in favor of parsing #comments instead? Given that # is
currently already being parsed (ignored), it shouldn't add too much
complexity to the code.
I am not sure what you have in mind, but IMO any solution would live
better as long as a solution is:
- not linked to hba.c, handled in a separate code path.
- linked to all configuration files where comments are supported, if
need be.
Perhaps others have more opinions.
--
Michael
On 01.09.23 12:44, Michael Paquier wrote:
I am not sure what you have in mind, but IMO any solution would live
better as long as a solution is:
- not linked to hba.c, handled in a separate code path.
- linked to all configuration files where comments are supported, if
need be.
If I understood you correctly: You mean an independent feature that i.e.
gets raw lines and parses the inline #comments.
Doing so we could indeed avoid the trouble of messing around with the
hba.c logic, and it would be accessible to other config files. Very
interesting thought! It sounds like a much more elegant solution.
Perhaps others have more opinions.
--
Michael
If I hear no objections, I'll try to sketch it as you suggested.
Thanks again for the feedback
Jim