Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
От | Tom Lane |
---|---|
Тема | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |
Дата | |
Msg-id | 13647.1515685358@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
|
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > While reviewing another patch related to the use of pg_strcasecmp in the > backend, I have noticed this bit in ruleutils.c: > /* > * Some GUC variable names are 'LIST' type and hence must not > * be quoted. > */ > if (pg_strcasecmp(configitem, "DateStyle") == 0 > || pg_strcasecmp(configitem, "search_path") == 0) > appendStringInfoString(&buf, pos); > else > simple_quote_literal(&buf, pos); > However this fails to consider all GUCs marked as GUC_LIST_INPUT, like > the recent wal_consistency_checking. Mmm, yeah, probably time to find a more maintainable solution to that. > guc.c already holds a find_option() > which can be used to retrieve the flags of a parameter. What about using > that and filtering by GUC_LIST_INPUT? This requires exposing the > function, and I am not sure what people think about that. Don't like exposing find_option directly, but I think it would make sense to provide an API along the lines of int GetConfigOptionFlags(const char *name, bool missing_ok). regards, tom lane
В списке pgsql-hackers по дате отправления: