Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, pavel(dot)stehule(at)gmail(dot)com, a(dot)zakirov(at)postgrespro(dot)ru, michael(dot)paquier(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs
Date: 2018-03-16 01:25:35
Message-ID: 20180316012535.GE2666@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 15, 2018 at 06:48:36PM +0900, Kyotaro HORIGUCHI wrote:
> postgres=# CREATE FUNCTION func_with_set_params() RETURNS integer
> AS 'select 1;'
> LANGUAGE SQL
> set plpgsql.extra_errors to 'shadowed_variables'
> set work_mem to '48MB'
> set plpgsql.extra_warnings to 'shadowed_variables';
> ERROR: the module for variable "plpgsql.extra_errors" is not loaded yet
> DETAIL: The module must be loaded before referring this variable.

How can you be sure that a parameter actually exists? A function
definition could as well use a parameter which does not exist, but you
would get this error as well, no? I find that error and handling a bit
confusing.

> postgres=# load 'plpgsql';
> [...]
> pg_get_functiondef() can work correctly with this even if
> required modules are not loaded.

Yeah, but the neck to any approaches here is that many applications may
rely on the existing behavior, and would miss the fact that they need to
load a module manually.

> But, I suppose it is a bit too big.

That's of course not backpatchable.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2018-03-16 01:46:46 Re: [HACKERS] plpgsql - additional extra checks
Previous Message Alvaro Herrera 2018-03-16 01:24:36 Re: User defined data types in Logical Replication