Re: Feature request: Connection string parsing for postgres_fdw

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Eric Hanson <eric(at)aquameta(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 13:39:11
Message-ID: CAExHW5tsrbQo7ii+WNJ0YyPZJF_DiqMvzyww8kQO=P8PaTV5jQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 23, 2020 at 6:35 PM Eric Hanson <eric(at)aquameta(dot)com> wrote:
>
> I'm trying to store connection to postgres_fdw in the database I want to be able to store the full breadth of connection styles and all the different types of connections that libpq supports. But having some troubles.
>
> Postgres_fdw wants options passed into CREATE SERVER, all broken out into separate variables, but this format is neither a connection URI, nor a keyword/value string. One could imagine writing some parser that extracts all the variables and honors collisions in the same way libpq does (like when both the path and the query string specify a port), but I really don't want to recreate that.
>
> It would be really nice if I could tap into libpq's connection string parser from SQL and use it to extract all the variables in a given connection string, so that I can then pipe those into CREATE SERVER options. Either that, or teach postgres_fdw how to consume standard connection strings.
>
> Suggestions? Is this worthy of a feature request?
>

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.

--
Best Wishes,
Ashutosh Bapat

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniil Zakhlystov 2020-12-23 13:39:39 Re: libpq compression
Previous Message Jammie 2020-12-23 13:35:56 Re: Movement of restart_lsn position movement of logical replication slots is very slow