Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Mon, Mar 19, 2018 at 07:15:36PM -0400, Tom Lane wrote:
> This is a good thing not least because all the GUC_LIST_QUOTE variables
> are in core. I've been trying to think of a way that we could have
> correct behavior for variables that the core backend doesn't know about
> and whose extension shlibs aren't currently loaded, and I can't come up
> with one. So I think that in practice, we have to document that
> GUC_LIST_QUOTE is unsupported for extension variables

I would propose to add a sentence on the matter at the bottom of the
CREATE FUNCTION page. Even with that, the handling of items in the list
is incorrect with any patches on this thread: the double quotes should
be applied to each element of the list, not the whole list. For example
with HEAD and this function:
=# CREATE or replace FUNCTION func_with_set_params() RETURNS integer
AS 'select 1;'
LANGUAGE SQL
SET search_path TO 'pg_catalog, public'
SET wal_consistency_checking TO heap, heap2
SET session_preload_libraries TO 'foo, bar'
IMMUTABLE STRICT;

Then retrieving the function definition results in that:
=# SELECT pg_get_functiondef('func_with_set_params'::regproc);
CREATE OR REPLACE FUNCTION public.func_with_set_params()
RETURNS integer
LANGUAGE sql
IMMUTABLE STRICT
SET search_path TO "pg_catalog, public"
SET wal_consistency_checking TO 'heap, heap2'
SET session_preload_libraries TO '"foo, bar"'
AS $function$select 1;$function$

And that's wrong as "pg_catalog, public" is only a one-element list, no?

> (and, perhaps,
> enforce this in DefineCustomStringVariable? or is that cure worse than
> the disease?)

Extension authors can just mark the variables they define with
GUC_LIST_QUOTE, so enforcing it would be a step backwards in my
opinion.
--
Michael