Re: Can we remove support for standard_conforming_strings = off yet?

Hi

út 30. 12. 2025 v 6:29 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
>

+1

Regards

Pavel

>
> regards, tom lane
>
>
>