Hi út 30. 12. 2025 v 6:29 odesílatel Tom Lane <[email protected]> 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. > +1 Regards Pavel > > regards, tom lane > > >
