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
|
Список | 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 по дате отправления: