Simon Riggs wrote:
> On Tue, 2009-04-14 at 18:29 -0400, Tom Lane wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> 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.
Extract the source of the offending plpgsql function using e.g pg_dump,
modify it so that it works again, and restore the function. There's your
workaround.
I haven't been following what the issues we have with the current
plpgsql lexer are, so I'm not sure what I think of the plan as a whole.
Sharing the main lexer seems like a good idea, but it also seems like
it's way too late in the release cycle for such changes. But then again,
if we have issues that need to be fixed anyway, it might well be the
best way to fix them.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
