Re: Feature request: Connection string parsing for postgres_fdw

Поиск
Список
Период
Сортировка
От Eric Hanson
Тема Re: Feature request: Connection string parsing for postgres_fdw
Дата
Msg-id CACA6kxjpzJp30bHTiBKfMk5CDRswyfwA3qUn+T21Drm8gf5OUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature request: Connection string parsing for postgres_fdw  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: Feature request: Connection string parsing for postgres_fdw  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


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"

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
--


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Borisov
Дата:
Сообщение: Re: [PATCH] Automatic HASH and LIST partition creation
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: proposal - support tsv output format for psql