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

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

=?UTF-8?q?R=C3=A9mi=20Lapeyre?= <remi(dot)lapeyre(at)lenstra(dot)fr> writes:
> The PGDATABASE is documented as behaving the same as the dbname connection
> parameter but they differ in the support for postgres:// URIs: the
> PGDATABASE will never be expanded even thought expand_dbname is set:

I think you have misunderstood the documentation. What you are
proposing is equivalent to saying that this should work:

$ psql -d "dbname=postgres://localhost/test"
psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL: database "postgres://localhost/test" does not exist

That doesn't work, never has, and I think it would be a serious
compatibility break and possibly a security hazard if it did.
The argument of "dbname=" should not be subject to another round
of interpretation, and neither should the content of the PGDATABASE
environment variable.

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.

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. (The lack of
clarity about how that should work is an important part of why
I don't like the idea of letting dbname/PGDATABASE supply anything
but the database name.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2023-04-17 01:33:43 Re: longfin missing gssapi_ext.h
Previous Message Michael Paquier 2023-04-16 22:22:58 Re: Direct I/O