On Tue, 1 Dec 2009 09:59:17 +0100, Dave Page <dp...@pgadmin.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
