Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
От | Tom Lane |
---|---|
Тема | Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl |
Дата | |
Msg-id | 192638.1675015507@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: Fix GUC_NO_SHOW_ALL test scenario in 003_check_guc.pl
|
Список | pgsql-hackers |
Justin Pryzby <pryzby@telsasoft.com> writes: > SELECT pg_show_all_settings() ought to keep working when called with no > parameter. Tom gave me a hint how to do that for system catalogs here: > https://www.postgresql.org/message-id/17988.1584472261@sss.pgh.pa.us > In this case, it might be cleaner to add a second entry to pg_proc.dat > than to add "CREATE OR REPLACE FUNCTION" to system_functions.sql (I > tried but couldn't get that to work just now). I kind of think this is a lot of unnecessary work. The case that is problematic is a GUC that's marked GUC_NO_SHOW_ALL but not marked GUC_NOT_IN_SAMPLE. There aren't any of those, and I don't think there are likely to be any in future, because it doesn't make a lot of sense. Why don't we just make a policy against doing that, and enforce it with an assertion somewhere in GUC initialization? regards, tom lane
В списке pgsql-hackers по дате отправления: