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

Re: Application name patch - v4

From: Brar Piening <brar(at)gmx(dot)de>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Application name patch - v4
Date: 2009-12-01 11:54:03
Message-ID: 4B1503DB.2020108@gmx.de (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page <dpage(at)pgadmin(dot)org> wrote:

> I do see the argument that RESET ALL should revert user changes to
> application_name though, but I maintain they should reset to the value
> set at connection time, not to null. As has been pointed out already,
> other values set at connection time cannot be reset, so allowing that
> for application name does seem like a POLA violation.
>   
I'd like to support this Argument.

As I understand this patch from 
http://archives.postgresql.org/pgsql-hackers/2009-10/msg00711.php it is 
intended to support some kind of feature like the SQL Server 
"...;Application Name=MyApp;..." connection string value, making the 
name of the user level (or whatever) application name available at the 
Database/SQL level.
I don't know about pgpool but as far as I know, some client side 
connection pooling implementations use one pool per connection 
string/url (.Net Data Providers, JDBC).
They would probably want set the application_name in the startup message 
and will expect it to fall back to this value when calling RESET ALL (or 
what ever you like to be the command to go back to the values that were 
requested on connection startup) on recycling a connection from the pool.
Any other solution would greatly complicate recycling of connections for 
per connection string pooling szenarios.

Regards,

Brar

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2009-12-01 11:58:03
Subject: Re: Block-level CRC checks
Previous:From: Euler Taveira de OliveiraDate: 2009-12-01 11:52:08
Subject: Re: ProcessUtility_hook

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