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

From Peter Eisentraut
Subject Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module
Date
Msg-id e69e7e05-2f8f-e478-480c-5f39180d6e21@2ndquadrant.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>)
Responses RE: [HACKERS] Proposal to add work_mem option to postgres_fdw module
List pgsql-hackers
On 28/08/2018 05:55, Shinoda, Noriyoshi (PN Japan GCS Delivery) wrote:
>>> 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.

We already have a method for libpq applications to pass GUC settings via
connection parameters.  And postgres_fdw supports passing libpq
connection parameters as server options.  So why doesn't this work here?

The reason is that postgres_fdw filters out connection settings that are
marked debug ("D"), and the "options" keyword is marked as such.  I
think this is wrong.  Just remove that designation and then this will
work.  (Perhaps filtering out the debug options is also wrong, but I can
see an argument for it.)

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #15346: Replica fails to start after the crash
Next
From: Andrey Borodin
Date:
Subject: B-tree cache prefetches