Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Artur Zakirov <a.zakirov@postgrespro.ru>

From: Arthur Zakirov <a.zakirov@postgrespro.ru>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: michael@paquier.xyz, tgl@sss.pgh.pa.us, pavel.stehule@gmail.com, michael.paquier@gmail.com, pgsql-hackers@postgresql.org
Date: 2018-03-15T10:33:51Z
Lists: pgsql-hackers
On Thu, Mar 15, 2018 at 06:48:36PM +0900, Kyotaro HORIGUCHI wrote:
> So, we should reject to define function in the case. We don't
> accept the GUC element if it is just a placeholder.
> 
> The attached is a rush work of my idea. Diff for pg_proc.h is too
> large so it is separated and gziped.
> 
> It adds a column named "proconfigislist" of array(bool) in
> pg_proc. When defined function has set clauses, it generates a
> proconfig-is-list-or-not array and set. It ends with error if
> required module is not loaded yet. Perhaps
> GetConfigOptionFlags(,false) shouldn't return 0 if no option
> element is found but I don't amend it for now.

I think your approach has a vulnerability too. I believe that a
non GUC_LIST_INPUT extension GUC which was used to create a function may
become GUC_LIST_INPUT variable. If I'm not mistaken nothing stops from
that. In this case values in proconfigislist won't be valide anymore.

-- 
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company


Commits

  1. Prevent extensions from creating custom GUCs that are GUC_LIST_QUOTE.

  2. Fix mishandling of quoted-list GUC values in pg_dump and ruleutils.c.