| From: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, 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-16 10:38:31 |
| Message-ID: | 20180316103830.GA4172@zakirov.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Mar 16, 2018 at 10:21:39AM +0900, Michael Paquier wrote:
> On Thu, Mar 15, 2018 at 01:33:51PM +0300, Arthur Zakirov wrote:
> > 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.
>
> I don't understand what you mean here. Are you referring to a custom
> GUC which was initially declared as not being a list, but became a list
> after a plugin upgrade with the same name?
Yes exactly. Sorry for the unclear message.
> Isn't the author to blame in this case?
Maybe he is. It may be better to rename a variable if it became a list.
I haven't strong opinion here though. I wanted to point the case where
proconfigislist column won't work.
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2018-03-16 10:43:56 | Re: ON CONFLICT DO UPDATE for partitioned tables |
| Previous Message | Pavel Stehule | 2018-03-16 10:31:41 | Re: missing support of named convention for procedures |