On Tue, 2009-04-14 at 18:29 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Tue, 2009-04-14 at 16:37 -0400, Tom Lane wrote:
> >> Comments, objections, better ideas?
>
> > Please, if you do this, make it optional.
>
> I don't think making the plpgsql lexer pluggable is realistic.
Doesn't sound easy, no. (I didn't suggest pluggable, just optional).
> > Potentially changing the behaviour of thousands of functions just to fix
> > a rare bug will not endear us to our users. The bug may be something
> > that people are relying on in some subtle way, ugly as that sounds.
>
> That's why I don't want to change it in a minor release. In a major
> release, however, it's fair game.
If we want to make easy upgrades a reality, this is the type of issue we
must consider. Not much point having perfect binary upgrades if all your
functions start behaving differently after upgrade and then you discover
there isn't a binary downgrade path...
Rather than come up with specific solutions, let me just ask the
question: Is there a workaround for people caught by these changes?
Let's plan that alongside the change itself, so we have a reserve
'chute.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
