Thread: Speaking of breaking compatibility...standard_conforming_strings
<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I just noticed this comment in scan.l:</div><divclass="gmail_default" style="font-family:arial,helvetica,sans-serif"><br /></div><div class="gmail_default"style=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">/*</div><div class="gmail_default"style="font-family:arial,helvetica,sans-serif"> * GUC variables. This is a DIRECT violation of thewarning given at the</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> * head of gram.y,ie flex/bison code must not depend on any GUC variables;</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> *as such, changing their values can induce very unintuitive behavior.</div><divclass="gmail_default" style="font-family:arial,helvetica,sans-serif"> * But we shall have to live withit as a short-term thing until the switch</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> *to SQL-standard string syntax is complete.</div><div class="gmail_default"style="font-family:arial,helvetica,sans-serif"> */</div><div class="gmail_default" style=""><div class="gmail_default"style=""><font face="arial, helvetica, sans-serif">int<span class="" style="white-space:pre"> </span>backslash_quote= BACKSLASH_QUOTE_SAFE_ENCODING;</font></div><div class="gmail_default" style=""><font face="arial,helvetica, sans-serif">bool<span class="" style="white-space:pre"> </span>escape_string_warning = true;</font></div><divclass="gmail_default" style=""><font face="arial, helvetica, sans-serif">bool<span class="" style="white-space:pre"></span>standard_conforming_strings = true;</font></div><div class="gmail_default" style=""><fontface="arial, helvetica, sans-serif"><br /></font></div><div class="gmail_default" style="">I'm not exactlysure what else needs to happen to remove these forbidden GUCs and if we are not prepared to do this now when willwe ever be...</div><div class="gmail_default" style=""><br /></div><div class="gmail_default" style="">David J.</div><divclass="gmail_default" style=""><br /></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br/></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br/></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br/></div></div></div>
"David G. Johnston" <david.g.johnston@gmail.com> 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 induce very unintuitive behavior.
> * But we shall have to live with it as a short-term thing until the switch
> * to SQL-standard string syntax is complete.
> */
> int backslash_quote = BACKSLASH_QUOTE_SAFE_ENCODING;
> bool escape_string_warning = true;
> bool standard_conforming_strings = true;
> I'm not exactly sure what else needs to happen to remove these forbidden
> GUCs and if we are not prepared to do this now when will we ever be...
Dunno, are you prepared to bet that nobody is turning off
standard_conforming_strings anymore?
In any case, we keep adding new violations of this rule (cf
operator_precedence_warning) so I have little hope that it will ever be
completely clean.
regards, tom lane
"David G. Johnston" <david.g.johnston@gmail.com> 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 induce very unintuitive behavior.
> * But we shall have to live with it as a short-term thing until the switch
> * to SQL-standard string syntax is complete.
> */
> int backslash_quote = BACKSLASH_QUOTE_SAFE_ENCODING;
> bool escape_string_warning = true;
> bool standard_conforming_strings = true;
> I'm not exactly sure what else needs to happen to remove these forbidden
> GUCs and if we are not prepared to do this now when will we ever be...
Dunno, are you prepared to bet that nobody is turning off
standard_conforming_strings anymore?
In any case, we keep adding new violations of this rule (cf
operator_precedence_warning) so I have little hope that it will ever be
completely clean.
I tend to hold the same position. I'd probably update the last sentence of the comment to reflect that reality.
"We use them here due to the user-facing capability to change the parsing rules of SQL-standard string literals."
The switch is not likely to ever be "complete" and if so not likely in whatever period the future reader might consider "short-term".
David J.
"David G. Johnston" <david.g.johnston@gmail.com> 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 induce very unintuitive behavior.
> * But we shall have to live with it as a short-term thing until the switch
> * to SQL-standard string syntax is complete.
> */
> int backslash_quote = BACKSLASH_QUOTE_SAFE_ENCODING;
> bool escape_string_warning = true;
> bool standard_conforming_strings = true;
> I'm not exactly sure what else needs to happen to remove these forbidden
> GUCs and if we are not prepared to do this now when will we ever be...
Dunno, are you prepared to bet that nobody is turning off
standard_conforming_strings anymore?
In any case, we keep adding new violations of this rule (cf
operator_precedence_warning) so I have little hope that it will ever be
completely clean.I tend to hold the same position. I'd probably update the last sentence of the comment to reflect that reality."We use them here due to the user-facing capability to change the parsing rules of SQL-standard string literals."The switch is not likely to ever be "complete" and if so not likely in whatever period the future reader might consider "short-term".
FWIW I'm not intending to dig any deeper in this area of the codebase. I was actually trying to find "gram.y" via a GitHub search (OT - I'm finding that to be not the most usable tool...need to get better at git cli) and ended up seeing scan.l
so I figured I'd read a few lines and got hit with that. I was trying to formulate an opinion of the "USING opclass" thread...decided that I'd take a pass on that at this time.
David J.
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 <tgl@sss.pgh.pa.us> wrote: > > "David G. Johnston" <david.g.johnston@gmail.com> 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 induce very unintuitive behavior. > > * But we shall have to live with it as a short-term thing until the > switch > > * to SQL-standard string syntax is complete. > > */ > > int backslash_quote = BACKSLASH_QUOTE_SAFE_ENCODING; > > bool escape_string_warning = true; > > bool standard_conforming_strings = true; > > > I'm not exactly sure what else needs to happen to remove these forbidden > > GUCs and if we are not prepared to do this now when will we ever be... > > Dunno, are you prepared to bet that nobody is turning off > standard_conforming_strings anymore? > > In any case, we keep adding new violations of this rule (cf > operator_precedence_warning) so I have little hope that it will ever be > completely clean. > > > I tend to hold the same position. I'd probably update the last sentence of > the comment to reflect that reality. I changed it to: * But we shall have to live with it until we can remove these variables. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +