Re: DISCARD ALL ; stored procedures - Mailing list pgsql-hackers

From Robert Haas
Subject Re: DISCARD ALL ; stored procedures
Date
Msg-id AANLkTi=V9RaG3VsYQUYeCzwQNaEzyR9FXuCnph93wfgu@mail.gmail.com
Whole thread Raw
In response to Re: DISCARD ALL ; stored procedures  (Stephen Frost <sfrost@snowman.net>)
Responses Re: DISCARD ALL ; stored procedures  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Fri, Jan 7, 2011 at 8:43 AM, Stephen Frost <sfrost@snowman.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
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Florian Pflug
Date:
Subject: Re: Snapshot synchronization, again...
Next
From: Magnus Hagander
Date:
Subject: Re: Streaming base backups