From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pavel(dot)stehule(at)gmail(dot)com, a(dot)zakirov(at)postgrespro(dot)ru, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs |
Date: | 2018-03-20 00:39:51 |
Message-ID: | 20180320003951.GA4963@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-03-20 00:40:53 | Re: committing inside cursor loop |
Previous Message | Amit Langote | 2018-03-20 00:34:23 | Re: inserts into partitioned table may cause crash |