On Wed, Apr 17, 2013 at 6:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No, it's a critical tool in complexity management. When you're dealing
> with systems as complicated as a database, every little non-orthogonal
> detail adds up. DISCARD ALL has a clear definition in terms of simpler
> commands, and it's going to stay that way. Either this is worth a
> subcommand, or it's not worth worrying about at all.
We had this same argument back in November of 2008. Marko said:
http://www.postgresql.org/message-id/24710.1227732351@sss.pgh.pa.us
And Greg Stark said:
http://www.postgresql.org/message-id/87iqqapag2.fsf@oxford.xeocode.com
And you said:
http://www.postgresql.org/message-id/24710.1227732351@sss.pgh.pa.us
And then you did this:
commit e309739670ac8c2fa0b236d116fcd44b0522025a
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu Nov 27 00:28:06 2008 +0000
Tweak wording of DISCARD ALL description to avoid giving the impression that the presented list of equivalent
operationsis meant to be the primary definition of what it does. Per comment from Guillaume Smet.
So it seems to me that we pretty much already made a decision that the
controlling definition of DISCARD ALL is that, as the fine manual says
"DISCARD ALL resets a session to its original state". Whatever
decision we make now ought to be consistent with that.
IOW, I don't care whether we introduce a new subcommand or not. But I
*do* think that that we ought to make our best effort to have DISCARD
ALL clear everything that smells like session-local state. Random
incompatibilities between what you see when running under a connection
pooler and what you see when connecting the DB directly are *bad*,
regardless of whether a well-designed application should be relying on
those particular things or not. The whole point of having a
transparent connection pooler is that it's supposed to be transparent
to the application.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company