Re: Application name patch - v4

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
Subject: Re: Application name patch - v4
Date: 2009-12-01 08:59:17
Message-ID: 937d27e10912010059j44e556fr8d4827bd632c99e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> Actually I think the poolers make a good case for a SET variant which emulates
> connection set variables...
>
> RESET ALL in a connection pooler does different things than RESET ALL outside
> of one.

Eh? Not sure I follow that, but then I haven't had a coffee yet.

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.

Upthread, Tom suggested a new 'SET DEFAULT ...' variant of SET which
could be used to set the default GUC value that RESET would revert to.
This seems to me to be the ideal solution, and I'd somewhat hesitantly
volunteer to work on it (hesitantly as it means touching the parser
and other areas of the code I currently have no experience of).

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2009-12-01 09:11:49 Re: Application name patch - v4
Previous Message Simon Riggs 2009-12-01 08:47:24 Re: Block-level CRC checks