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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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