Re: Feature request: Connection string parsing for postgres_fdw

From: Eric Hanson <eric(at)aquameta(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Feature request: Connection string parsing for postgres_fdw
Date: 2020-12-23 14:12:36
Message-ID: CACA6kxjpzJp30bHTiBKfMk5CDRswyfwA3qUn+T21Drm8gf5OUw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 23, 2020 at 5:39 AM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)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"

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

Eric
--
http://aquameta.org/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2020-12-23 14:21:36 Re: proposal - support tsv output format for psql
Previous Message Pavel Borisov 2020-12-23 14:03:28 Re: [PATCH] Automatic HASH and LIST partition creation