Speaking of breaking compatibility...standard_conforming_strings

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

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

On Tue, May 24, 2016 at 4:07 PM, David G. Johnston <
david.g.johnston@gmail.com> 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.

"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 +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers