Re: [PATCH] Add support for postgres:// URIs to PGDATABASE environment variable

From: Rémi Lapeyre <remi(dot)lapeyre(at)lenstra(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add support for postgres:// URIs to PGDATABASE environment variable
Date: 2023-04-17 09:07:05
Message-ID: E00DFD4D-20ED-4ECC-B5A0-A24F8EF637FC@lenstra.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Le 17 avr. 2023 à 03:25, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> a écrit :
>
> You can do this:
>
> $ psql -d "postgres://localhost/test"
>
> but that's not the same thing as reinterpreting the dbname field
> of what we have already determined to be a connection string.
>

Yes, I know see the difference, I got confused by the way the code reuses the dbname keyword to pass the connection string and the fact that

$ psql --dbname "postgres://localhost/test"

works, but the dbname parameter of psql is not the same as the dbname used by libpq.

> Perhaps there is a case for inventing a new environment variable
> that can do what you're suggesting. But you would have to make
> a case that it's worth doing, and also define how it interacts
> with all the other PGxxx environment variables.

I think it could be convenient to have such an environment variable but given your feedback I will just make it specific to my application rather than a part of libpq.

Best,
Rémi

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-04-17 09:55:28 Re: Add two missing tests in 035_standby_logical_decoding.pl
Previous Message Kyotaro Horiguchi 2023-04-17 08:47:41 Re: eclg -C ORACLE breaks data