RE: [HACKERS] Proposal to add work_mem option to postgres_fdw module - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan GCS Delivery)
Subject RE: [HACKERS] Proposal to add work_mem option to postgres_fdw module
Date
Msg-id TU4PR8401MB04300F56F7EB0EDECE87CB2EEE0A0@TU4PR8401MB0430.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module  (Fabrízio de Royes Mello <fabriziomello@gmail.com>)
Responses Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module
Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module
List pgsql-hackers
Hi Everyone, thank you for your comment. 

>> I like the direction of your thinking, but it seems to me that this
>> would cause a problem if you want to set search_path=foo,bar.
>... OPTIONS ( host 'remhost1', port '5433', dbname 'demodb', option='option1=foo', option='option2=bar' );

I do not want to allow postgres_fdw to set "all" GUCs. Because I think it is very difficult to check the validity of
allinput values.
 
So, I attached modified the patch so that we can easily add GUC that we can set to postgres_fdw module.
If you wish to add more GUC options to the module, add values to the non_libpq_options[] array of the InitPgFdwOptions
function,
And add the validator code for the GUC in the postgres_fdw_validator function.

Best Regards,
Noriyoshi Shinoda

-------------
From: Fabrízio de Royes Mello [mailto:fabriziomello@gmail.com] 
Sent: Tuesday, August 28, 2018 3:53 AM
To: [pgdg] Robert Haas <robertmhaas@gmail.com>
Cc: michael@paquier.xyz; Shinoda, Noriyoshi (PN Japan GCS Delivery) <noriyoshi.shinoda@hpe.com>; Pgsql Hackers
<pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module



On Mon, Aug 27, 2018 at 3:35 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Aug 27, 2018 at 1:29 AM Michael Paquier <michael@paquier.xyz> wrote:
> > It seems to me that you would pass down just a string which gets
> > allocated for "options", and injection risks are something to be careful
> > about.  Another possibility would be an array with comma-separated
> > arguments, say:
> > options = 'option1=foo,option2=bar'
> > There is already some work done with comma-separated arguments for the
> > parameter "extensions", now that's more work.
>
> I like the direction of your thinking, but it seems to me that this
> would cause a problem if you want to set search_path=foo,bar.
>

Maybe we can use multiple "options". Something like:

... OPTIONS ( host 'remhost1', port '5433', dbname 'demodb', option='option1=foo', option='option2=bar' );

Regards,

--
   Fabrízio de Royes Mello         Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

Attachment

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: Pluggable Storage - Andres's take
Next
From: David Rowley
Date:
Subject: typcache.c typos