Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Michael Paquier writes: > On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote: >> I don't mind making it an ereport, but I think it needs to be FATAL >> for the reason stated in the comment. > Okay for the FATAL. I can see that at this time of the day your patch > 0002

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Mar 21, 2018 at 01:40:23AM -0400, Tom Lane wrote: > Michael Paquier writes: >> On Tue, Mar 20, 2018 at 01:27:35PM -0400, Tom Lane wrote: >>> + if (flags & GUC_LIST_QUOTE) >>> + elog(FATAL, "extensions cannot define GUC_LIST_QUOTE >>> variables");

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Michael Paquier writes: > On Tue, Mar 20, 2018 at 01:27:35PM -0400, Tom Lane wrote: >> + if (flags & GUC_LIST_QUOTE) >> + elog(FATAL, "extensions cannot define GUC_LIST_QUOTE >> variables"); > This would be better as an ereport with

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Tue, Mar 20, 2018 at 01:27:35PM -0400, Tom Lane wrote: > 1. Only GUC_LIST_QUOTE variables need to be special-cased. It works > fine to treat plain LIST variables (e.g. datestyle) with the regular > code path. This is good because there are so few of them. Check. > 2. We should make an

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

So here's what I think we should do about this: 1. Only GUC_LIST_QUOTE variables need to be special-cased. It works fine to treat plain LIST variables (e.g. datestyle) with the regular code path. This is good because there are so few of them. 2. We should make an effort to minimize the number

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Mon, 19 Mar 2018 23:07:13 -0400, Tom Lane wrote in <10037.1521515...@sss.pgh.pa.us> > Michael Paquier writes: > > 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 >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Michael Paquier writes: > 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

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

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

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Kyotaro HORIGUCHI writes: > At Fri, 16 Mar 2018 21:15:54 +0900, Michael Paquier > wrote in <20180316121554.ga2...@paquier.xyz> >> Let's be clear. I have listed all the variables in the patch to gather >> more easily opinions, and because it

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

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

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-16 9:34 GMT+01:00 Kyotaro HORIGUCHI : > At Fri, 16 Mar 2018 09:16:54 +0100, Pavel Stehule > wrote in zyujawdnu...@mail.gmail.com> > > 2018-03-16 5:46 GMT+01:00 Michael Paquier

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Fri, 16 Mar 2018 09:16:54 +0100, Pavel Stehule wrote in > 2018-03-16 5:46 GMT+01:00 Michael Paquier : > > > On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote: > >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-16 5:46 GMT+01:00 Michael Paquier : > On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote: > >> But, I suppose it is a bit too big. > > > > That's of course not backpatchable. > > So in this jungle attached is my counter-proposal. As the same code >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Fri, Mar 16, 2018 at 10:25:35AM +0900, Michael Paquier wrote: >> But, I suppose it is a bit too big. > > That's of course not backpatchable. So in this jungle attached is my counter-proposal. As the same code pattern is repeated in three places, we could as well refactor the whole into a

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

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

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

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

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

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. >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Thu, 15 Mar 2018 15:09:54 +0900, Michael Paquier wrote in <20180315060954.ge...@paquier.xyz> > On Thu, Mar 15, 2018 at 02:03:15PM +0900, Kyotaro HORIGUCHI wrote: > > At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in > >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Thu, Mar 15, 2018 at 02:03:15PM +0900, Kyotaro HORIGUCHI wrote: > At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in > <22193.1521088...@sss.pgh.pa.us> >> Kyotaro HORIGUCHI writes: >>> Doesn't it make sense if we provide a

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

At Thu, 15 Mar 2018 00:33:25 -0400, Tom Lane wrote in <22193.1521088...@sss.pgh.pa.us> > Kyotaro HORIGUCHI writes: > > Doesn't it make sense if we provide a buildtime-script that > > collects the function names and builds a .h file containing

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Kyotaro HORIGUCHI writes: > Doesn't it make sense if we provide a buildtime-script that > collects the function names and builds a .h file containing a > function using the list? Surely this is a fundamentally misguided approach. How could it handle extension

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Hello, At Wed, 14 Mar 2018 17:46:21 +0900, Michael Paquier wrote in <20180314084621.ga...@paquier.xyz> > On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote: > > Doesn't it make sense if we provide a buildtime-script that > > collects the function names and

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Mar 14, 2018 at 05:30:59PM +0900, Kyotaro HORIGUCHI wrote: > Doesn't it make sense if we provide a buildtime-script that > collects the function names and builds a .h file containing a > function using the list? > > The attached perl script is a rush work of such script, which > works at

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Hello, At Tue, 6 Mar 2018 07:14:00 +0100, Pavel Stehule wrote in

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-03-06 2:32 GMT+01:00 Michael Paquier : > On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote: > > I afraid so there is not good solution. Is possible to store options in > > original form? When the function will be displayed, then the original > value > > will

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Mon, Mar 05, 2018 at 09:25:09PM +0100, Pavel Stehule wrote: > I afraid so there is not good solution. Is possible to store options in > original form? When the function will be displayed, then the original value > will be displayed. The current patch (with known extensions) can be used as > bug

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

2018-02-21 8:35 GMT+01:00 Michael Paquier : > On Tue, Feb 20, 2018 at 06:46:57PM +0300, Arthur Zakirov wrote: > > Just 2 cents from me. It seems that there is a problem with extensions > > GUCs. > > > > [...] > > > > =# SELECT

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Wed, Feb 21, 2018 at 04:35:50PM +0900, Michael Paquier wrote: > You have an excellent point here, and I did not consider it. > For pg_dump and pg_dumpall, something like what I described in > https://www.postgresql.org/message-id/20180112012440.ga2...@paquier.xyz > to extend pg_settings so as

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Tue, Feb 20, 2018 at 06:46:57PM +0300, Arthur Zakirov wrote: > Just 2 cents from me. It seems that there is a problem with extensions > GUCs. > > [...] > > =# SELECT pg_get_functiondef('func_with_set_params'::regproc); > ERROR: unrecognized configuration parameter "plpgsql.extra_errors" You

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Hello, On Fri, Jan 12, 2018 at 10:24:40AM +0900, Michael Paquier wrote: > OK, I can live with that. What do you think about the attached? I'll be > happy to produce patches for back-branches as necessary. When an option > is not found, I have made the function return 0 as value for the flags, >

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

On Thu, Jan 11, 2018 at 10:42:38AM -0500, Tom Lane wrote: > Michael Paquier writes: >> guc.c already holds a find_option() >> which can be used to retrieve the flags of a parameter. What about using >> that and filtering by GUC_LIST_INPUT? This requires exposing the >>

Re: pg_get_functiondef forgets about most GUC_LIST_INPUT GUCs

Michael Paquier writes: > While reviewing another patch related to the use of pg_strcasecmp in the > backend, I have noticed this bit in ruleutils.c: > /* > * Some GUC variable names are 'LIST' type and hence must not > * be quoted. > */ > if