Skip site navigation (1) Skip section navigation (2)

Re: BUG #5304: psql using conninfo fails in connecting to the server

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server
Date: 2010-02-03 02:05:49
Message-ID: 4B68D9FD.6010708@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On 02/02/2010 05:59 PM, Tom Lane wrote:
> This seems bogus on a couple of levels.  First off, I thought the idea
> was to get away from using PQsetdbLogin at all.  If we go down this path
> we'll never be rid of it.  Second, to preserve backwards compatibility
> we will have to duplicate this same type of logic in any of the other
> places we want to replace PQsetdbLogin (because it's actually
> PQsetdbLogin that implements the dbname-containing-equal-sign special
> case in prior releases).  I count nine remaining calls of that function
> between bin/ and contrib/, at least some of which were supposed to get
> application_name-ified before release.

> While I'm looking at this, there's another bogosity in the original
> patch: it neglected the PQsetdbLogin call in psql/command.c, meaning
> that doing \c would result in losing the application_name setting.

OK, based on this and the similar complaint fro Fujii-san, I guess I'll
have another go at it. I didn't understand that this patch was leading
to replacement of PQsetdbLogin() entirely -- should I go ahead and
eliminate use of PQsetdbLogin() in our source tree now?

> concern is still valid in 2010, but if it is, this doesn't fix it.
> This doesn't do very much to help with the maintenance risk about
> keeping the two arrays in step, either --- now there's neither a
> direct nor a visual matchup between the entries.  I'd suggest
> something like
> 
> 	keywords[0] = "host";
> 	values[0] = options.host;
> 	keywords[1] = "port";
> 	values[1] = options.port;

Will do.

Joe



In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-03 02:10:57
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server
Previous:From: Tom LaneDate: 2010-02-03 02:00:47
Subject: Re: rbtree test data

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-02-03 02:10:57
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server
Previous:From: Tom LaneDate: 2010-02-03 01:59:20
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group