From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |
Date: | 2018-01-11 15:42:38 |
Message-ID: | 13647.1515685358@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Diego Silva e Silva | 2018-01-11 15:52:10 | The first function call |
Previous Message | Alvaro Herrera | 2018-01-11 15:42:24 | Re: CUBE seems a bit confused about ORDER BY |