On 12/17/2014 04:11 AM, Heikki Linnakangas wrote:
On 12/17/2014 10:03 AM, Albe Laurenz wrote:
David Fetter wrote:
I've noticed that psql's \c function handles service= requests in a
way that I can only characterize as broken.
This came up in the context of connecting to a cloud hosting service
named after warriors or a river or something, whose default hostnames
are long, confusing, and easy to typo, so I suspect that service= may
come up more often going forward than it has until now.
For example, when I try to use
\c "service=foo"
It will correctly figure out which database I'm trying to connect to,
but fail to notice that it's on a different host, port, etc., and
hence fail to connect with a somewhat unhelpful error message.
I can think of a few approaches for fixing this:
0. Leave it broken.
1. Disable "service=" requests entirely in \c context, and error
out if attempted.
2. Ensure that \c actually uses all of the available information.
Is there another one I missed?
If not, which of the approaches seems reasonable?
#2 is the correct solution, #1 a band aid.
It would be handy, if \c "service=foo" actually worked. We should do
#3. If the database name is actually a connection string, or a service
specification, it should not re-use the hostname and port from
previous connection, but use the values from the connection string or
service file.
Yeah, that's the correct solution. It should not be terribly difficult
to create a test for a conninfo string in the dbname parameter. That's
what libpq does after all. We certainly don't want psql to have to try
to interpret the service file. psql just needs to let libpq do its work
in this situation.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
