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