Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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:

In response to


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group