From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module |
Date: | 2019-12-18 00:12:11 |
Message-ID: | CAMkU=1wOGSZyCdv5HpWXhgZqwoYXsV0PB9SLKbzJW9Sv0JeSUg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 7, 2018 at 9:17 AM Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 05/09/2018 18:46, Peter Eisentraut wrote:
> > On 01/09/2018 06:33, Shinoda, Noriyoshi (PN Japan GCS Delivery) wrote:
> >> Certainly the PQconndefaults function specifies Debug flag for the
> "options" option.
> >> I think that eliminating the Debug flag is the simplest solution.
> >> For attached patches, GUC can be specified with the following syntax.
> >>
> >> CREATE SERVER remsvr1 FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host
> 'host 1', ..., options '-c work_mem=64MB -c geqo=off');
> >> ALTER SERVER remsv11 OPTIONS (SET options '-c work_mem=64MB -c
> geqo=off');
> >>
> >> However, I am afraid of the effect that this patch will change the
> behavior of official API PQconndefaults.
> >
> > It doesn't change the behavior of the API, it just changes the result of
> > the API function, which is legitimate and the reason we have the API
> > function in the first place.
> >
> > I think this patch is fine. I'll work on committing it.
>
> I have committed just the libpq change. The documentation change was
> redundant, because the documentation already stated that all libpq
> options are accepted. (Arguably, the documentation was wrong before.)
>
Since the effect of this commit was to make postgres_fdw actually comply
with its documentation,
should this have been back-patched? Is there a danger in backpatching this
change to libpq to older versions?
This seems like more of a bug fix than an added feature.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-12-18 00:18:18 | Re: [PATCH] Fix possible underflow in expression (maxoff - 1) |
Previous Message | Michael Paquier | 2019-12-17 23:40:24 | Re: non-exclusive backup cleanup is mildly broken |