On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to affect "just this function" and not spill to nested
functions as is the case for SETs now.
I can't imagine how that would work for anyone who has thousands of
How's that fundamentally different from changing languages? If we had a
way to *add* such attributes to *existing* functions I don't see the
Adding 5-10 of these for every function you create seems significantly
more painful than saying "this function uses plpgsql2". Though perhaps
what's being suggested is a *single* option which changes everything at
once? Then there wouldn't be a huge difference.
I've tried my best over the past ~year or so, but any attempts at breaking
backwards compatibility have been rejected. I really don't see any gradual
way of doing this. We either break things, live with what we have right
now, or create a new language.
I think to some degree that was also influenced by the approach you
took. Several of the changes didn't really have a meaningful explanation
why they'd be helpful in the field. I.e. the change was explained, but
not the reasoning *leading* to the change and which other solutions you
Yes, I agree I didn't always do a terrific job (see: EXIT USING
ROLLBACK), but some of them have been outright rejected even though
people clearly saw the value (I would put ASSERT into that category, and
the change to SELECT .. INTO obviously belongs here).
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: