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

From Masahiko Sawada
Subject Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module
Date
Msg-id CAD21AoD4b4L7xOho_9niCVc38aRfx010oUCyQ-eDK-f4vVfBPQ@mail.gmail.com
Whole thread Raw
In response to RE: [HACKERS] Proposal to add work_mem option to postgres_fdw module  ("Shinoda, Noriyoshi (PN Japan GCS Delivery)" <noriyoshi.shinoda@hpe.com>)
List pgsql-hackers
On Tue, Aug 28, 2018 at 12:55 PM, Shinoda, Noriyoshi (PN Japan GCS
Delivery) <noriyoshi.shinoda@hpe.com> wrote:
> 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
InitPgFdwOptionsfunction,
 
> And add the validator code for the GUC in the postgres_fdw_validator function.
>

FWIW, in term of usability I'm not sure that setting GUCs per foreign
servers would be useful for users. The setting parameters per foreign
servers affects all statements that touches it, which is different
behavior from the local some parameters, especially for query tuning
parameters. Is it worth to consider another ways to specify GUC
parameter per statements or transactions?

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Olivier Leprêtre
Date:
Subject: TR: pgadmin not displaying data from postgresql_fdw
Next
From: Peter Eisentraut
Date:
Subject: Re: remove ancient pre-dlopen dynloader code