Re: Replacing plpgsql's lexer - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Replacing plpgsql's lexer
Date
Msg-id 4136ffa0904150256p5c160c34mb7f6584accef4f5a@mail.gmail.com
Whole thread Raw
In response to Re: Replacing plpgsql's lexer  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Replacing plpgsql's lexer  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Replacing plpgsql's lexer  (Robert Haas <robertmhaas@gmail.com>)
Re: Replacing plpgsql's lexer  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Apr 15, 2009 at 10:12 AM, Simon Riggs <simon@2ndquadrant.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.

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.

One of free software's big advantages over commercial software is that
it moves so much more quickly. Oracle, AIX, Windows, etc are burdened
by hundreds of layers of backwards-compatibility which take up a huge
portion of their development and Q/A effort. The reason Linux,
Postgres, and others have been able to come up so quickly and overtake
them is partly because we don't worry about such things.

As far as I'm concerned commercial support companies can put effort
into developing backwards-compatibility modules which add no long-term
value for their paying customers who need it today while the free
software developers can keep improving the software for new users.

-- 
greg


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Replacing plpgsql's lexer
Next
From: Simon Riggs
Date:
Subject: Re: Replacing plpgsql's lexer