On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.com> writes:
>
> > No, at least both pgbouncer and pgpool consider only (username, database)
> > pair as pool identifier. Rest of the startup params are tuned on the fly.
> > And I think that should stay that way.
>
>
> If you're happy with handling the existing connection parameters in a given
> way, why would you not want application_name behaving that same way?
Well, in pgbouncer case, the parameters tracked via ParamStatus are
handled transparently. (client_encoding, datestyle, timezone,
standard_conforming_strings)
Any other parameter is handled via "ignore_startup_parameters" option:
if client supplies random option not appearing there, it is kicked out.
The point being that as pgbouncer cannot handle it transparently, the
admin needs to set the param in postgresql.conf if it is important,
fix the client or let pgbouncer ignore it if client is unfixable.
I have no problem handling appname with latter method, I just wanted
to clarify the target audience for the feature.
--
marko