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

From Dave Page
Subject Re: Application name patch - v4
Date
Msg-id 937d27e10912010059j44e556fr8d4827bd632c99e@mail.gmail.com
Whole thread Raw
In response to Re: Application name patch - v4  (Andres Freund <andres@anarazel.de>)
Responses Re: Application name patch - v4  (Andres Freund <andres@anarazel.de>)
Re: Application name patch - v4  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Re: Application name patch - v4  (Brar Piening <brar@gmx.de>)
List pgsql-hackers
On Tue, Dec 1, 2009 at 12:26 AM, Andres Freund <andres@anarazel.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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Block-level CRC checks
Next
From: Andres Freund
Date:
Subject: Re: Application name patch - v4