út 30. 12. 2025 v 6:29 odesílatel Tom Lane <tgl@sss.pgh.pa.us> napsal:
standard_conforming_strings has defaulted to ON since 2010 (see 0839f312e in the 9.1 release). I propose that it's finally time to force it on and get rid of code that supports the "off" setting.
Aside from pure code removal, there are nontrivial benefits that will accrue:
* The setting has always been a bit of a security hazard, since client code that escapes strings assuming one setting is at big risk of SQL injection if the server is actually using the other. We've disclaimed such issues as not-our-problem, but that doesn't make them not a hazard.
* As discussed in the NOTES at the head of src/backend/parser/gram.y, it's not okay for raw parsing to depend on changeable GUCs. Sure, gram.y doesn't use that setting; but scan.l does, so it's broken and dangerous. (See also the comment in scan.l above the declaration of standard_conforming_strings.)
The code-removal aspect shouldn't be minimized either. There's a nontrivial portion of scan.l that isn't reachable unless standard_conforming_strings is off, and reducing the size of the lexer probably translates directly to performance benefits.
I would envision this working similarly to what we previously did with default_with_oids: the GUC still exists so that applications can query it, and we even allow you to explicitly set it to 'on'; only setting it to 'off' will fail.
I haven't looked into subsidiary questions such as whether we can similarly lobotomize escape_string_warning, or when it'd be okay to remove the client-side support for non-standard-conforming strings in the psql and ecpg lexers. I'll push forward on those questions if there's consensus that doing something about this is acceptable in principle.
