Re: Feature request: Connection string parsing for postgres_fdw

Поиск
Список
Период
Сортировка
От Eric Hanson
Тема Re: Feature request: Connection string parsing for postgres_fdw
Дата
Msg-id CACA6kxjS89CnD8b0AxVRKOtMHxORdfXA9uELEr5Aso+FyhNDiQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Feature request: Connection string parsing for postgres_fdw  (Ian Lawrence Barwick <barwick@gmail.com>)
Список pgsql-hackers
Whoa that's perfect!  Thank you so much.

On Thu, Dec 24, 2020 at 4:59 PM Ian Lawrence Barwick <barwick@gmail.com> wrote:
2020年12月23日(水) 22:05 Eric Hanson <eric@aquameta.com>:
>
> 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.

Does something like this do what you're looking for?

    postgres=# SELECT * FROM conninfo_parse('host=node1 user=foo');
     keyword | value
    ---------+-------
     user    | foo
     host    | node1
    (2 rows)

    postgres=# SELECT * FROM conninfo_parse('postgresql://localhost:5433');
     keyword |   value
    ---------+-----------
     host    | localhost
     port    | 5433
    (2 rows)

Basically a wrapper around PQconninfoParse(), I've had the code knocking around
for a while now and finally got round to packaging it into an
extension [1]. It's
on my todo list to submit a patch based on this to core, as it seems Generally
Useful To Have.

[1] https://github.com/ibarwick/conninfo

Regards

Ian Barwick
--
EnterpriseDB: https://www.enterprisedb.com

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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: doc review for v14
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Rethinking plpgsql's assignment implementation