Hi Michael
On 16.09.23 06:18, Michael Paquier wrote:
> That was the idea. I forgot about strpos(), but if you do that, do we
> actually need a function in core to achieve that?
I guess it depends who you ask :) I personally think it would be a good
addition to the view, as it would provide a more comprehensive look into
the hba file. Yes, the fact that it could possibly be written in SQL
sounds silly, but it's IMHO still relevant to have it by default.
> There are a few fancy cases with the SQL function you have sent,
> actually.. strpos() would grep the first '#' character, ignoring
> quoted areas.
Yes, you're totally right. I didn't take into account any token
surrounded by double quotes containing #.
v3 attached addresses this issue.
From the following hba:
host db jim 192.168.10.1/32 md5 # foo
host db jim 192.168.10.2/32 md5 #bar
host db jim 192.168.10.3/32 md5 # #foo#
host "a#db" "a#user" 192.168.10.4/32 md5 # fancy #hba entry
We can get these records from the view:
SELECT type, database, user_name, address, comment
FROM pg_hba_file_rules
WHERE address ~~ '192.168.10.%';
type | database | user_name | address | comment
------+----------+-----------+--------------+------------------
host | {db} | {jim} | 192.168.10.1 | foo
host | {db} | {jim} | 192.168.10.2 | bar
host | {db} | {jim} | 192.168.10.3 | #foo#
host | {a#db} | {a#user} | 192.168.10.4 | fancy #hba entry
I am still struggling to find a way to enable this function in separated
path without having to read the conf file multiple times, or writing too
much redundant code. How many other conf files do you think would profit
from this feature?
Jim