| From: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
|---|---|
| To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | michael(at)paquier(dot)xyz, tgl(at)sss(dot)pgh(dot)pa(dot)us, pavel(dot)stehule(at)gmail(dot)com, 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-15 10:33:51 |
| Message-ID: | 20180315103350.GA29606@zakirov.localdomain |
| 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:
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2018-03-15 10:35:03 | Re: Failed to request an autovacuum work-item in silence |
| Previous Message | Meenatchi Sandanam | 2018-03-15 10:18:35 | PostgreSQL opens all the indexes of a relation for every Query during Planning Time? |