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