Re: Replacing plpgsql's lexer

On Wed, Apr 15, 2009 at 5:56 AM, Greg Stark <stark(at)enterprisedb(dot)com> wrote:
> On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>> How do you know which is the offending function? If we force a full
>> application retest we put in place a significant barrier to upgrade.
>> That isn't useful for us as developers, nor is it useful for users.
>
> This is a fundamental conflict, not one that has a single simple answer.
>
> However this seems like a strange place to pick your battle. Something
> as low-level as the lexer is very costly to provide multiple
> interfaces to. It's basically impossible short of simply providing two
> different plpgsql languages -- something which won't scale at all if
> we have to do it every time we make a syntax change to the language.

Completely agreed.

> I'm actually concerned that we've become *too* conservative. Pretty
> much any change that doesn't have Tom's full support and credibility
> standing behind it ends up being criticized on the basis that we don't
> know precisely what effects it will have in every possible scenario.

I think we've become too conservative in some areas and not
conservative enough in others. In particular, we're not very
conservative AT ALL about changes to the on-disk format - which is
like unto a bullet through the head for in-place upgrade. And we
sometimes make behavior changes that have potentially catastrophic
user consequences (like that one to TRUNCATE... which one, you ask?
ah, well, you'd better not use TRUNCATE in 8.4 until you RTFM then),
but then we'll have an argument about whether it's OK to make some
change where it's difficult to image the user impact being all that
severe, like:

- this one
- removing the special case for %% in the log_filename
- forward-compatible, backward-compatible improvements to CREATE OR REPLACE VIEW
- lots of others

So it seems that there is no consistent heuristic (other than, as you
say, Tom's approval or lack thereof) applied to these changes.

...Robert