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@gmail.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@article.se> wrote:
>>
>> The following bug has been logged on the website:
>>
>> Bug reference: 10692
>> Logged by: Pontus Lundkvist
>> Email address: p@article.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@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>
>