Re: Application name patch - v4 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Application name patch - v4
Date
Msg-id 16595.1259702412@sss.pgh.pa.us
Whole thread Raw
In response to Re: Application name patch - v4  (Marko Kreen <markokr@gmail.com>)
Responses Re: Application name patch - v4  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
Marko Kreen <markokr@gmail.com> writes:
> On 12/1/09, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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)

Hmm, I had not thought about that.  Is it sensible to mark
application_name as GUC_REPORT so that pgbouncer can be smart about it?
The actual overhead of such a thing would be probably be unmeasurable in
the normal case where it's only set via the startup packet, but it seems
a bit odd.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: Application name patch - v4
Next
From: Greg Smith
Date:
Subject: Re: [CORE] EOL for 7.4?