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: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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 06:01:13
Message-ID: 4B691129.9000008@joeconway.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
On 02/02/2010 06:40 PM, Tom Lane wrote:
> The difference with PQconnectdbParams is that the dbname might not be
> the first thing in the parameter array.  I think that a straightforward
> implementation would have the effect of the expanded dbname overriding
> parameters given before it, but not those given after it.  Consider
> 
> 	keyword[0] = "port";
> 	values[0] = "5678";
> 	keyword[1] = "dbname";
> 	values[1] = "dbname = db user = foo port = 9999";
> 	keyword[2] = "user";
> 	values[2] = "uu";
> 
> What I'm imagining is that this would end up equivalent to
> dbname = db user = uu port = 9999.  That's probably reasonable,
> and maybe even useful, as long as it's documented.

No doc changes yet, and I still have not corrected the earlier mentioned
issue,

> 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.

but I wanted to get feedback before going further.

This patch implements Tom's idea above. Note that I also rearranged the
parameters for the call from psql so that dbname is last, therefore
allowing a conninfo to override all other settings. The result looks like:

	keywords[0]	= "host";
	values[0]	= options.host;
	keywords[1]	= "port";
	values[1]	= options.port;
	keywords[2]	= "user";
	values[2]	= options.username;
	keywords[3]	= "password";
	values[3]	= password;
	keywords[4]	= "application_name";
	values[4]	= pset.progname;
	keywords[5]	= "dbname";
	values[5]	= (options.action == ACT_LIST_DB &&
			options.dbname == NULL) ?
			"postgres" : options.dbname;
	keywords[6]	= NULL;
	values[6]	= NULL;

Which produces:

# psql -U postgres "dbname=regression user=fred application_name='joe\'s
app'"
psql (8.5devel)
Type "help" for help.

regression=> select backend_start, application_name from pg_stat_activity ;
         backend_start         | application_name
-------------------------------+------------------
 2010-02-02 21:44:55.969202-08 | joe's app
(1 row)

regression=> select current_user;
 current_user
--------------
 fred
(1 row)

Are there any of the psql parameters that we do not want to allow to be
overridden by the conninfo string?


Joe

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-02-03 06:08:36
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server
Previous:From: Tom LaneDate: 2010-02-03 05:50:35
Subject: Re: Add on_trusted_init and on_untrusted_init to plperl UPDATED [PATCH]

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-02-03 06:08:36
Subject: Re: BUG #5304: psql using conninfo fails in connecting to the server
Previous:From: Jasen BettsDate: 2010-02-03 05:53:37
Subject: Re: whole-row functional index?

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