postgresql.git/src/test/regress/sql/strings.sql, branch master

Add battery of tests related TOAST tables with oid8

2026-09-15T02:30:45Z

The tests added by this commit cover a large ground in terms of the introduction of oid8 in TOAST tables, with the following areas covered, with all the gaps found during the development of the feature: - Tables with oid8 TOAST tables in general, under strings.sql. - ALTER TABLE with attribute manipulations in transactions and different toast_table_value settings. - Relation rewrites, not affecting the TOAST relation after initial creation with VACUUM FULL, CLUSTER, REPACK. - pg_column_compression(). - test_decoding, for external and extended TOAST data. - amcheck, external and extended storage with heap checked. - UPDATE with out-of-line datums that belongs to another TOAST table. This offers coverage for toast_tuple_init(), where external vartags could be mixed once multiple on-disk external TOAST pointers can co-exist. This pattern can be triggered with asan/ubsan, with an out-of-bound memcpy when unpatched. These tests are added before the new vartag_external, mostly as a matter of avoiding dead code in the tree. Author: Michael Paquier Reviewed-by: Greg Burd Reviewed-by: Bharath Rupireddy Reviewed-by: Yugo Nagata Discussion: https://postgr.es/m/af19kUjwjhaoUTLn@paquier.xy

Fix truncation rules for base64 encoding

2026-07-17T13:40:16Z

Commit e1d917182 added support for base64url encoding, a base64 variant intended to be safe for usage in URLs and filenames. The padding rules for base64url and base64 differ in that base64url require no extra '=' padding, but the commit unintentionally relaxed this requirement for base64 as well. Fix by making sure that the truncation logic check for the encoding and add a test to make sure. Backpatch down to v19 where support for base64url was introduced. Author: Daniel Gustafsson Reviewed-by: David E. Wheeler Discussion: https://postgr.es/m/3258FC72-F5E1-40B9-B5D7-64478CAF7728@yesql.se Backpatch-through: 19

Add base32hex support to encode() and decode() functions.

2026-03-25T18:35:19Z

This adds support for base32hex encoding and decoding, as defined in RFC 4648 Section 7. Unlike standard base32, base32hex uses the extended hex alphabet (0-9, A-V) which preserves the lexicographical order of the encoded data. This is particularly useful for representing UUIDv7 values in a compact string format while maintaining their time-ordered sort property. The encode() function produces output padded with '=', while decode() accepts both padded and unpadded input. Following the behavior of other encoding types, decoding is case-insensitive. Suggested-by: Sergey Prokhorenko Author: Andrey Borodin Co-authored-by: Aleksander Alekseev Reviewed-by: Masahiko Sawada Reviewed-by: Илья Чердаков Reviewed-by: Chengxi Sun Reviewed-by: Chao Li Discussion: https://postgr.es/m/CAJ7c6TOramr1UTLcyB128LWMqita1Y7%3Darq3KHaU%3Dqikf5yKOQ%40mail.gmail.com

Add more tests with clause STORAGE on table and TOAST interactions

2026-01-26T00:30:22Z

This commit adds more tests to cover STORAGE MAIN and EXTENDED, checking how these use TOAST tables. EXTENDED is already widely tested as the default behavior, but there were no tests where the clause pattern is directly specified. STORAGE MAIN and its interactions with TOAST was not covered at all. This hole in the tests has been noticed for STORAGE MAIN (inline compressible varlenas), where I have managed to break the backend without the tests able to notice the breakage while playing with the varlena structures. Reviewed-by: Nikhil Kumar Veldanda Discussion: https://postgr.es/m/aXMdX1UTHnzYPkHk@paquier.xyz

Force standard_conforming_strings to always be ON.

2026-01-21T20:08:38Z

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 Discussion: https://postgr.es/m/3279216.1767072538@sss.pgh.pa.us

Add HINT listing valid encodings to encode() and decode() errors.

2025-11-20T00:14:02Z

This commit updates encode() and decode() so that when an invalid encoding is specified, their error message includes a HINT listing all valid encodings. This helps users quickly see which encodings are supported without needing to consult the documentation. Author: Shinya Sugamoto Reviewed-by: Chao Li Reviewed-by: Daniel Gustafsson Reviewed-by: Masahiko Sawada Reviewed-by: Peter Eisentraut Reviewed-by: Nathan Bossart Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/CAAe3y+99sfPv8UDF1VM-rC1i5HBdqxUh=2HrbJJFm2+i=1OwOw@mail.gmail.com

Optimize hex_encode() and hex_decode() using SIMD.

2025-10-06T17:28:50Z

The hex_encode() and hex_decode() functions serve as the workhorses for hexadecimal data for bytea's text format conversion functions, and some workloads are sensitive to their performance. This commit adds new implementations that use routines from port/simd.h, which testing indicates are much faster for larger inputs. For small or invalid inputs, we fall back on the existing scalar versions. Since we are using port/simd.h, these optimizations apply to both x86-64 and AArch64. Author: Nathan Bossart Co-authored-by: Chiranmoy Bhattacharya Co-authored-by: Susmitha Devanga Reviewed-by: John Naylor Discussion: https://postgr.es/m/aLhVWTRy0QPbW2tl%40nathan

Add support for base64url encoding and decoding

2025-09-20T21:19:32Z

This adds support for base64url encoding and decoding, a base64 variant which is safe to use in filenames and URLs. base64url replaces '+' in the base64 alphabet with '-' and '/' with '_', thus making it safe for URL addresses and file systems. Support for base64url was originally suggested by Przemysław Sztoch. Author: Florents Tselai Reviewed-by: Aleksander Alekseev Reviewed-by: David E. Wheeler Reviewed-by: Masahiko Sawada Reviewed-by: Daniel Gustafsson Reviewed-by: Chao Li (Evan) Discussion: https://postgr.es/m/70f2b6a8-486a-4fdb-a951-84cef35e22ab@sztoch.pl

Amend recent fix for SIMILAR TO regex conversion.

2025-09-13T20:55:51Z

Commit e3ffc3e91 fixed the translation of character classes in SIMILAR TO regular expressions. Unfortunately the fix broke a corner case: if there is an escape character right after the opening bracket (for example in "[\q]"), a closing bracket right after the escape sequence would not be seen as closing the character class. There were two more oversights: a backslash or a nested opening bracket right at the beginning of a character class should remove the special meaning from any following caret or closing bracket. This bug suggests that this code needs to be more readable, so also rename the variables "charclass_depth" and "charclass_start" to something more meaningful, rewrite an "if" cascade to be more consistent, and improve the commentary. Reported-by: Dominique Devienne Reported-by: Stephan Springl Author: Laurenz Albe Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAFCRh-8NwJd0jq6P=R3qhHyqU7hw0BTor3W0SvUcii24et+zAw@mail.gmail.com Backpatch-through: 13

Add regression test for short varlenas saved in TOAST relations

2025-08-06T08:22:03Z

toast_save_datum() has for a very long time some code able to handle short varlenas (values up to 126 bytes reduced to a 1-byte header), converting such varlenas to an external on-disk TOAST pointer with the value saved uncompressed in the secondary TOAST relation. There was zero coverage for this code path. This commit adds a test able to exercise it, relying on two external attributes, one with a low toast_tuple_target, so as it is possible to trigger the threshold for the insertion of short varlenas into the TOAST relation. Author: Nikhil Kumar Veldanda Co-authored-by: Michael Paquier Discussion: https://postgr.es/m/aJAl7-NvIk0kZByz@paquier.xyz