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

From Simon Riggs
Subject Re: Replacing plpgsql's lexer
Date
Msg-id 1239791599.23905.10.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Replacing plpgsql's lexer  (Greg Stark <stark@enterprisedb.com>)
Responses Re: Replacing plpgsql's lexer  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
On Wed, 2009-04-15 at 10:56 +0100, Greg Stark wrote:
> 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. 

I think you are right that you perceive a fundamental conflict and most
things I say become battles. That is not my choice and I will withdraw
from further discussion. My point has been made clearly and has not been
made to cause conflict. I've better things to do with my time than that,
though it's a shame you think that of me.

> 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.

We will all doubtless make money from difficult upgrades, though that is
not my choice, nor that of my customers.

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Replacing plpgsql's lexer
Next
From: Magnus Hagander
Date:
Subject: Re: Why isn't stats_temp_directory automatically created?