Re: Replacing plpgsql's lexer

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Replacing plpgsql's lexer
Дата
Msg-id 1239778670.16396.164.camel@ebony.2ndQuadrant
обсуждение исходный текст
Ответ на Re: Replacing plpgsql's lexer  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Replacing plpgsql's lexer  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Why isn't stats_temp_directory automatically created?
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: New trigger option of pg_standby