Re: Allow file inclusion in pg_hba and pg_ident files
| От | Michael Paquier |
|---|---|
| Тема | Re: Allow file inclusion in pg_hba and pg_ident files |
| Дата | |
| Msg-id | YkFrhurzrXuX6dnF@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Allow file inclusion in pg_hba and pg_ident files (Julien Rouhaud <rjuju123@gmail.com>) |
| Ответы |
Re: Allow file inclusion in pg_hba and pg_ident files
|
| Список | pgsql-hackers |
On Mon, Mar 28, 2022 at 03:43:41PM +0800, Julien Rouhaud wrote: > On Mon, Mar 28, 2022 at 04:20:07PM +0900, Michael Paquier wrote: >> We could use a failure path for each psql command rather than a SKIP >> block, as you told me, if the psql fails and check that we get some >> error strings related to the loading of auth files. However, I am >> scared of this design in the long-term as it could cause the tests to >> pass with a failure triggered on platforms and/or configurations where >> we should have a success. So, I am tempted to drop the ball for now >> with the TAP part. > > Ok. We could still keep the tests for the valid lines part though? With the SQLs modified as below, this part is less interesting. >> The patch still has value for the end-user. I have checked the >> backend part, and I did not notice any obvious issue. There is one >> thing that I am wondering though: should we change the two queries in >> sysviews.sql so as we check that there are zero errors in the two >> views when the files are parsed? This simple change would avoid >> mistakes for users running installcheck on a production installation. > > Do you mean something like > > SELECT count(*) > 0 AS ok, > count(*) FILTER (WHERE error IS NOT NULL) = 0 AS has_no_error > FROM pg_hba_file_rules ; > > and similar for pg_ident_rule_mappings? Something like that, yes. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: