Re: BUG #10692: psql: \c service=foo only uses dbname information

From: Pontus Lundkvist <p(at)article(dot)se>
To: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #10692: psql: \c service=foo only uses dbname information
Date: 2014-06-19 13:01:28
Message-ID: CAAH1o6RHBg2d1ph76--zsAZLeZJcDGtfhrT6uXcXePz96ir-yA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I've tried to track down the behavior a bit.

The reason service=foo works as a dbname, seems to be the PQconnectdbParams(,,
true)-call in psql/command.c, which is expand_dbname. This makes
conninfo_array_parse in the end try and recognize dbname as a connection string.

Didn't dig any further down that line; but I assume that's the service=foo
expansion magic is happening.

But, since user/host/port wasn't specified in \connect, they are copied from
the current connection. And I assume that overwrites whatever was parsed
from the service-definition.

On Thu, Jun 19, 2014 at 11:20 AM, hubert depesz lubaczewski
<depesz(at)gmail(dot)com> wrote:
> It's not a bug. At most - missing feature. There is no mention that you
> could use "service=" or anything like this in \c parameters. And - \? shows
> clearly that syntax for \connect options is very different.
>
> depesz
>
>
> On Wed, Jun 18, 2014 at 6:03 PM, <p(at)article(dot)se> wrote:
>>
>> The following bug has been logged on the website:
>>
>> Bug reference: 10692
>> Logged by: Pontus Lundkvist
>> Email address: p(at)article(dot)se
>> PostgreSQL version: 9.4beta1
>> Operating system: Debian sid
>> Description:
>>
>> Trying to connect to another database via \c and a service-definition,
>> it seems to ignore everything other than the dbname. This includes not
>> using either user or host.
>>
>> For a service-definition without dbname, it seems to act just like an
>> empty \c, reconnecting to the same connection.
>>
>> Expected result: Either oblivious to service=-dsn and failing hard,
>> or that the full service-definition is parsed and used.
>>
>>
>>
>> --
>> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Steven Siebert 2014-06-19 13:47:49 Re: BUG #10680: LDAP bind password leaks to log on failed authentication
Previous Message Stephen Frost 2014-06-19 12:44:32 Re: BUG #10680: LDAP bind password leaks to log on failed authentication