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

Re: DISCARD ALL ; stored procedures

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: DISCARD ALL ; stored procedures
Date: 2011-01-07 13:56:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jan 7, 2011 at 8:43 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> To be honest, I agree it's a bug, and I would *love* to have it
> back-patched, but I could see an argument for it to be something
> explicit from DISCARD PLANS; and would hence require a grammar
> change which isn't something we'd typically back-patch.

That argument doesn't carry much water with me, because it's hard for
me to imagine a situation where you need to discard one of these
things but discarding the other one also causes a problem.  I'm also
pretty unexcited about adding more stuff to the grammar to cover such
a marginal borderline case.  Adding unreserved keywords is pretty
cheap, but it's not totally free.  If we were going to do it I'd
suggest DISCARD LANGUAGE PLANS or something like that, but I don't
really see a reason to go there at all.

Really it seems to me that changing the search path ought to discard
anything that might have been done differently had the search path
been different, but I don't think that's back-patch material.

> Making it part of DISCARD PLANS; and back-patching it to 8.3 where
> DISCARD was introduced would be awesome for me. :)

I'd need to look at this more closely before committing anything, but
at first blush I think that's reasonable.  Have a patch?

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-07 14:45:22
Subject: Re: Streaming base backups
Previous:From: Florian PflugDate: 2011-01-07 13:47:55
Subject: Re: Snapshot synchronization, again...

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