| 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: | Whole Thread | Raw Message | 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 |