Client application name

Dave Page wrote:

The attached patch is a first quick cut of the basic functionality to
do this. Currently, it makes the following changes:

Couple of thoughts,

- should we use argv[0] automatically in libpq unless overridden?
- should we reject funny chars such as \n? (hopefully \0 won't be a
problem)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Dave Page wrote:

My questions to the group are:

- Is my approach reasonable?
- What interface should I include in libpq?

On the second question, obviously the user can call SET to set a
value, as I've done for now in psql, however in other DBMSs, it may be
set in the connection string. My feeling would be to do that, and
possibly add PQsetApplicationName(PGconn *conn, char *name) and char
*PQapplicationName(PGconn *conn);. What do others think?

Doing it with a GUC will not be nearly so useful as having it in the
wire protocol, IMNSHO. Just one example: it wouldn't be present in
connection records, because it wouldn't be set yet.

cheers

andrew

On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

Dave Page wrote:

The attached patch is a first quick cut of the basic functionality to
do this. Currently, it makes the following changes:

Couple of thoughts,

- should we use argv[0] automatically in libpq unless overridden?

How can I get to it from libpq? I could use getprogname() if present.

- should we reject funny chars such as \n? (hopefully \0 won't be a
problem)

Is there any need? I can't see that it would do any harm other than
maybe messing up some query output - and the solution would be 'don't
do that then' :-)

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

Doing it with a GUC will not be nearly so useful as having it in the wire
protocol, IMNSHO. Just one example: it wouldn't be present in connection
records, because it wouldn't be set yet.

I quite like the flexibility of being able to set/show a GUC at any
time, but you raise a good point. I'll need to venture into previously
unknown territory (for me at least :-p) to figure out how best to do
that, and if possible keep the GUC...

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page wrote:

On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

- should we reject funny chars such as \n? (hopefully \0 won't be a
problem)

Is there any need? I can't see that it would do any harm other than
maybe messing up some query output - and the solution would be 'don't
do that then' :-)

I worry about log_line_prefix expansion with an unexpected newline. I'm
not sure "don't do that" is a good enough answer because you might be
dealing with uncooperative application writers :-(

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Dave Page wrote:

On Tue, Oct 13, 2009 at 4:11 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

Doing it with a GUC will not be nearly so useful as having it in the wire
protocol, IMNSHO. Just one example: it wouldn't be present in connection
records, because it wouldn't be set yet.

I quite like the flexibility of being able to set/show a GUC at any
time, but you raise a good point. I'll need to venture into previously
unknown territory (for me at least :-p) to figure out how best to do
that, and if possible keep the GUC...

From time to time people ask for "scalar variable" facility. ISTM what
you're trying to do is just a special case of that. Maybe we could
approach it by providing a builtin (and non-removable)
custom_variable_classes entry ('pg_variables'?). Then you could have
clients safely do:

set pg_variables.client_name = 'blurfl';

And I'm sure other people would find interesting uses for such a gadget.

cheers

andrew

On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

From time to time people ask for "scalar variable" facility. ISTM what
you're trying to do is just a special case of that. Maybe we could approach
it by providing a builtin (and non-removable) custom_variable_classes entry
('pg_variables'?). Then you could have clients safely do:

  set pg_variables.client_name = 'blurfl';

And I'm sure other people would find interesting uses for such a gadget.

I'm not sure that's really related to this - for example, we wouldn't
want to push everything in the custom class through the logger or into
per-backend shared memory, which would mean special-casing this
particular variable for which doing those things is the primary use
case.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dave Page <dpage@pgadmin.org> writes:

- Is my approach reasonable?
- What interface should I include in libpq?

I thought the plan was to have libpq look at an environment variable,
compare PGCLIENTENCODING for example. I'm not convinced psql should be
involved in the logic at all --- if it is, there definitely must be a
way for scripts to override the "psql" value. In general the place that
is most reasonable to set the value might be several software levels up
from libpq, which is what makes the environment-variable approach
attractive.

regards, tom lane

Dave Page <dpage@pgadmin.org> writes:

On Tue, Oct 13, 2009 at 4:06 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

- should we use argv[0] automatically in libpq unless overridden?

How can I get to it from libpq?

You can't.

regards, tom lane

Dave Page <dpage@pgadmin.org> writes:

On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

From time to time people ask for "scalar variable" facility.

I'm not sure that's really related to this

It isn't; I think Andrew confused this thread with the one where someone
wanted to know about trigger context.

regards, tom lane

On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Page <dpage@pgadmin.org> writes:

- Is my approach reasonable?
- What interface should I include in libpq?

I thought the plan was to have libpq look at an environment variable,

I wasn't aware we had a plan :-)

compare PGCLIENTENCODING for example.  I'm not convinced psql should be
involved in the logic at all --- if it is, there definitely must be a
way for scripts to override the "psql" value.  In general the place that
is most reasonable to set the value might be several software levels up
from libpq, which is what makes the environment-variable approach
attractive.

The current implementation just has psql do SET application_name =
'psql'; immediately following connection to setup a sensible default.
That can be overridden at any time with another SET.

I can have libpq look at the environment as it does for
PGCLIENTENCODING, but I'd certainly like to be able to use the
connection string as well, as environment variables are not really the
first choice of a Windows programmer for such things. I'm not sure
psql should be looking directly at the environment though should it?
Or would you envisage it only SETing application_name itself, if libpq
didn't already have a value from elsewhere?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Tom Lane wrote:

Dave Page <dpage@pgadmin.org> writes:

On Tue, Oct 13, 2009 at 4:34 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

From time to time people ask for "scalar variable" facility.

I'm not sure that's really related to this

It isn't; I think Andrew confused this thread with the one where someone
wanted to know about trigger context.

I didn't but I'm multitasking and should stop.

cheers

andrew

On Tue, 13 Oct 2009, Dave Page wrote:

A useful feature found in other DBMSs such as MS SQL Server that has
been requested on these lists a few times, is the ability for a client
application to report its name to the server. This information may
then be presented in logs, activity reports and so on to aid debugging
and help the sysadmin/DBA see easily what activity is coming from
where on their server.

As a point of reference the JDBC API specifies the following which allows
multiple properties that are similar to the desired request which are
useful in a multi-tier application.

http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#setClientInfo(java.lang.String,%20java.lang.String)

Kris Jurka

I can have libpq look at the environment as it does for
PGCLIENTENCODING, but I'd certainly like to be able to use the
connection string as well, as environment variables are not really the

another challenge with the Environment variable: they are (at least on
windows) usually set for one logged on user.

And ususally I have pg_admin, python for development, psql and my
application all connected to the same PostgreSQL server.

I would love to see 4 different application names, and not the value of one
environment-variable. that argv[0] that was somewhere in this thread looked
nice :)

Harald

--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Spielberger Straße 49
70435 Stuttgart
0173/9409607
no fx, no carrier pigeon
-
%s is too gigantic of an industry to bend to the whims of reality

On Tuesday 13 October 2009 18:30:54 Massa, Harald Armin wrote:

I can have libpq look at the environment as it does for
PGCLIENTENCODING, but I'd certainly like to be able to use the
connection string as well, as environment variables are not really the

another challenge with the Environment variable: they are (at least on
windows) usually set for one logged on user.

And ususally I have pg_admin, python for development, psql and my
application all connected to the same PostgreSQL server.

I would love to see 4 different application names, and not the value of one
environment-variable. that argv[0] that was somewhere in this thread looked
nice :)

Well, those applications could set it themselves...

Andres

On Tue, Oct 13, 2009 at 12:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Page <dpage@pgadmin.org> writes:

- Is my approach reasonable?
- What interface should I include in libpq?

I thought the plan was to have libpq look at an environment variable,
compare PGCLIENTENCODING for example.  I'm not convinced psql should be
involved in the logic at all --- if it is, there definitely must be a
way for scripts to override the "psql" value.  In general the place that
is most reasonable to set the value might be several software levels up
from libpq, which is what makes the environment-variable approach
attractive.

What happens if we want to change the application name after the fact?
Consider the case where there is a connection pooler between the
database and application, for example.

...Robert

Robert Haas <robertmhaas@gmail.com> writes:

What happens if we want to change the application name after the fact?

As long as it's a GUC variable you can just do SET. I think the point
of discussion is what is the best convention for getting it set
initially.

regards, tom lane

On Tue, Oct 13, 2009 at 11:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:

What happens if we want to change the application name after the fact?
 Consider the case where there is a connection pooler between the
database and application, for example.

good point...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

Dave Page <dpage@pgadmin.org> writes:

On Tue, Oct 13, 2009 at 5:05 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Dave Page <dpage@pgadmin.org> writes:

- Is my approach reasonable?

I thought the plan was to have libpq look at an environment variable,

I wasn't aware we had a plan :-)

There was some previous discussion of this, which I am too lazy to look
up but I thought we had sketched out an API.

regards, tom lane