summaryrefslogtreecommitdiff
path: root/contrib/test_decoding
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2026-01-21 15:08:38 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2026-01-21 15:08:38 -0500
commit45762084545ec14dbbe66ace1d69d7e89f8978ac (patch)
tree6d2d711161725ec4d092caea6f79c168c758af88 /contrib/test_decoding
parent4d6a66f675815a5d40a650d4dcfb5ddb89c6ad2f (diff)
Force standard_conforming_strings to always be ON.
Continuing to support this backwards-compatibility feature has nontrivial costs; in particular it is potentially a security hazard if an application somehow gets confused about which setting the server is using. We changed the default to ON fifteen years ago, which seems like enough time for applications to have adapted. Let's remove support for the legacy string syntax. We should not remove the GUC altogether, since client-side code will still test it, pg_dump scripts will attempt to set it to ON, etc. Instead, just prevent it from being set to OFF. There is precedent for this approach (see commit de66987ad). This patch does remove the related GUC escape_string_warning, however. That setting does nothing when standard_conforming_strings is on, so it's now useless. We could leave it in place as a do-nothing setting to avoid breaking clients that still set it, if there are any. But it seems likely that any such client is also trying to turn off standard_conforming_strings, so it'll need work anyway. The client-side changes in this patch are pretty minimal, because even though we are dropping the server's support, most of our clients still need to be able to talk to older server versions. We could remove dead client code only once we disclaim compatibility with pre-v19 servers, which is surely years away. One change of note is that pg_dump/pg_dumpall now set standard_conforming_strings = on in their source session, rather than accepting the source server's default. This ensures that literals in view definitions and such will be printed in a way that's acceptable to v19+. In particular, pg_upgrade will work transparently even if the source installation has standard_conforming_strings = off. (However, pg_restore will behave the same as before if given an archive file containing standard_conforming_strings = off. Such an archive will not be safely restorable into v19+, but we shouldn't break the ability to extract valid data from it for use with an older server.) Author: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/3279216.1767072538@sss.pgh.pa.us
Diffstat (limited to 'contrib/test_decoding')
-rw-r--r--contrib/test_decoding/test_decoding.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/contrib/test_decoding/test_decoding.c b/contrib/test_decoding/test_decoding.c
index e104aa5aa6e..809382880a2 100644
--- a/contrib/test_decoding/test_decoding.c
+++ b/contrib/test_decoding/test_decoding.c
@@ -474,8 +474,8 @@ pg_decode_filter(LogicalDecodingContext *ctx,
* Print literal `outputstr' already represented as string of type `typid'
* into stringbuf `s'.
*
- * Some builtin types aren't quoted, the rest is quoted. Escaping is done as
- * if standard_conforming_strings were enabled.
+ * Some builtin types aren't quoted, the rest is quoted. Escaping is done
+ * per standard SQL rules.
*/
static void
print_literal(StringInfo s, Oid typid, char *outputstr)