You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A bytea value now reaches Ruby as a binary (ASCII-8BIT) String holding
its exact bytes -- NUL-safe -- rather than as its \x... hex text output,
and returning a String into a bytea takes the string's raw bytes
verbatim (any encoding), with no hex/escape parsing. This matches
PL/Python's bytea <-> bytes mapping.
The conversion is intercepted at the datum level (before the type's text
I/O) wherever a bytea crosses between SQL and Ruby:
- scalar arguments and bytea[] arguments (plruby_func_build_args)
- scalar and bytea[] return values (plruby_func_handler return path,
which otherwise NUL-truncates via the text-input path)
- composite fields, SPI result rows, and trigger $_TD (the shared
plruby_hash_from_tuple)
- fields, OUT params, and return_next rows via plruby_datum_from_value
FROM-SQL uses PG_DETOAST_DATUM_PACKED + VARDATA_ANY/VARSIZE_ANY_EXHDR
into an ASCII-8BIT string; TO-SQL builds the varlena directly from the
string's raw bytes. bytea[] shares the array datum walk, generalized to
convert elements binary-wise when no FromSQL transform applies.
BREAKING: bodies that produced or consumed the hex text form must be
updated (e.g. build bytes with [..].pack('C*') rather than a \x string).
Rewrote sql/bytea for the new semantics (round-trips with NULs, high
bytes, composite/SPI/array coverage). Full suite green on PG 12 and 18;
jsonb_plruby and hstore_plruby suites still pass (shared array walk).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments