Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

2016-06-21 Thread Bruce Momjian
On Tue, May 24, 2016 at 04:07:02PM -0400, David G. Johnston wrote: > On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote: > > "David G. Johnston" writes: > > I just noticed this comment in scan.l: > > /* > >  * GUC variables.  This is

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

2016-05-24 Thread David G. Johnston
On Tue, May 24, 2016 at 4:07 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote: > >> "David G. Johnston" writes: >> > I just noticed this comment in scan.l: >> > /* >> > * GUC variables.

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

2016-05-24 Thread David G. Johnston
On Tue, May 24, 2016 at 3:57 PM, Tom Lane wrote: > "David G. Johnston" writes: > > I just noticed this comment in scan.l: > > /* > > * GUC variables. This is a DIRECT violation of the warning given at the > > * head of gram.y, ie flex/bison

Re: [HACKERS] Speaking of breaking compatibility...standard_conforming_strings

2016-05-24 Thread Tom Lane
"David G. Johnston" writes: > I just noticed this comment in scan.l: > /* > * GUC variables. This is a DIRECT violation of the warning given at the > * head of gram.y, ie flex/bison code must not depend on any GUC variables; > * as such, changing their values can

[HACKERS] Speaking of breaking compatibility...standard_conforming_strings

2016-05-24 Thread David G. Johnston
I just noticed this comment in scan.l: /* * GUC variables. This is a DIRECT violation of the warning given at the * head of gram.y, ie flex/bison code must not depend on any GUC variables; * as such, changing their values can induce very unintuitive behavior. * But we shall have to live with