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
signature.asc
Description: OpenPGP digital signature
