Hi,
On Fri, Mar 25, 2022 at 08:18:31PM +0900, Michael Paquier wrote:
>
> Now looking at 0002. The changes in hba.c are straight-forward,
> that's a nice read.
Thanks!
> if (!field) { \
> - ereport(LOG, \
> + ereport(elevel, \
> (errcode(ERRCODE_CONFIG_FILE_ERROR), \
> errmsg("missing entry in file \"%s\" at end of line %d", \
> IdentFileName, line_num))); \
> + *err_msg = psprintf("missing entry at end of line"); \
> return NULL; \
> } \
> I think that we'd better add to err_msg the line number and the file
> name. This would become particularly important once the facility to
> include files gets added. We won't use IdentFileName for this
> purpose, but at least we would know which areas to change. Also, even
> if the the view proposes line_number, there is an argument in favor of
> consistency here.
I don't really like it. The file inclusion patch adds a file_name column in
both views so that you have a direct access to the information, whether the
line is in error or not. Having the file name and line number in error message
doesn't add any value as it would be redundant, and just make the view output
bigger (on top of making testing more difficult). I kept the err_msg as-is
(and fixed the ereport filename in the file inclusion patch that I indeed
missed).
>
> +select count(*) >= 0 as ok from pg_ident_file_mappings;
>
> I'd really like to see more tests for this stuff
I didn't like the various suggestions, as it would mean to scatter the tests
all over the place. The whole point of those views is indeed to check the
current content of a file without applying the configuration change (not on
Windows or EXEC_BACKEND, but there's nothing we can do there), so let's use
this way. I added a naive src/test/authentication/003_hba_ident_views.pl test
that validates that specific new valid and invalid lines in both files are
correctly reported. Note that I didn't update those tests for the file
inclusion.
Note that those tests fail on Windows (and I'm assuming on EXEC_BACKEND
builds), as they're testing invalid files which by definition prevent any
further connection attempt. I'm not sure what would be best to do here, apart
from bypassing the invalid config tests on such platforms. I don't think that
validating that trying to connect on such platforms when an invalid
pg_hba/pg_ident file brings anything.
> + a.pg_usernamee,
> [...]
> + <entry role="catalog_table_entry"><para role="column_definition">
> + <structfield>pg_username</structfield> <type>text</type>
>
> Perhaps that's just a typo in the function output and you
> intended to use pg_username?
Yes that was a typo :) It's correctly documented in catalogs.sgml, so I just
fixed pg_proc.dat and rules.out.
> + /* Free parse_hba_line memory */
> + MemoryContextSwitchTo(oldcxt);
> + MemoryContextDelete(identcxt);
> Incorrect comment, this should be parse_ident_line.
Indeed. I actually fixed it before but lost the change when rebasing after the
2nd hbafuncs.c refactoring. I also fixed an incorrect comment about
pg_hba_file_mappings.