From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: Postgres hackers <pgsql-hackers@postgresql.org>
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
In-reply-to: <20180111064900.GA51030@paquier.xyz>
References: <20180111064900.GA51030@paquier.xyz>
Comments: In-reply-to Michael Paquier <michael.paquier@gmail.com>
	message dated "Thu, 11 Jan 2018 15:49:00 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <13646.1515685358.1@sss.pgh.pa.us>
Date: Thu, 11 Jan 2018 10:42:38 -0500
Message-ID: <13647.1515685358@sss.pgh.pa.us>
Precedence: bulk

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