Re: Feature request: Connection string parsing for postgres_fdw - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Feature request: Connection string parsing for postgres_fdw
Date
Msg-id CAExHW5tDDBikNxwkM3wM6gwnUQi27SOc7_Hn5M2eJT9NEEayuw@mail.gmail.com
Whole thread Raw
In response to Re: Feature request: Connection string parsing for postgres_fdw  (Eric Hanson <eric@aquameta.com>)
List pgsql-hackers
On Wed, Dec 23, 2020 at 7:42 PM Eric Hanson <eric@aquameta.com> wrote:
>
>
>
> On Wed, Dec 23, 2020 at 5:39 AM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote:
>>
>> https://www.postgresql.org/docs/13/libpq-connect.html#LIBPQ-PARAMKEYWORDS
>> lists the parameters that postgres_fdw accepts. "dbname" can be more
>> than just dbname. See
>> https://www.postgresql.org/docs/13/libpq-connect.html#LIBPQ-CONNSTRING.
>> And "dbname" is not in the list of exception paramters in section
>> "F.33.1.1. Connection Options" at
>> https://www.postgresql.org/docs/13/postgres-fdw.html#id-1.11.7.42.11.
>>
>> I haven't tried this myself. But this might help you.
>
>
> Good idea, but according to this thread:
> https://www.postgresql.org/message-id/878tjcbbgb.fsf%40ars-thinkpad
> "postgres_fdw forbids usage of connection strings by passing expand_dbname = false to PQconnectdbParams"

Looks like the documentation needs an update here.

>
> They discuss the reasoning here:  If it were to allow expand_dbname, people could override username etc, variables
thatneed to be fixed, by setting them in the dbname connection string.  But this just seems like a bug.  It should
prioritizenon-expanded variables over expanded ones. 

Yeah. That might be what the feature should implement.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: [Patch] Optimize dropping of relation buffers using dlist
Next
From: Tomas Vondra
Date:
Subject: Re: How is this possible "publication does not exist"