Use a safer outfuncs/readfuncs representation for BitStrings.
commitf15d01cb5dbdc44276f82178759586023896a3b7
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Feb 2024 17:18:25 +0000 (13 12:18 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 13 Feb 2024 17:18:25 +0000 (13 12:18 -0500)
tree57d9a44cc14785818eac78abf722e2b574ace320
parent103235888d9e74755ec4c7a72d640d4c7fabc596
Use a safer outfuncs/readfuncs representation for BitStrings.

For a long time, our outfuncs.c code has supposed that the string
contents of a BitString node could just be printed literally with
no concern for quoting/escaping.  Now, that's okay if the string
literal contains only valid binary or hex digits ... but our lexer
doesn't check that, preferring to let bitin() be the sole authority
on what's valid.  So we could have raw parse trees that contain
incorrect BitString literals, and that can result in failures when
WRITE_READ_PARSE_PLAN_TREES debugging is enabled.

Fix by using outToken() to print the string field, and debackslash()
to read it.  This results in a change in the emitted representation
only in cases that would have failed before, and don't represent valid
SQL in the first place.  Between that and the fact that we don't store
raw parse trees in the catalogs, I judge this safe to apply without a
catversion bump.

Per bug #18340 from Alexander Lakhin.  Back-patch to v16; before that,
we lacked readfuncs support for BitString nodes, so that the problem
was only cosmetic.

Discussion: https://postgr.es/m/18340-4aa1ae6ed4121912@postgresql.org
src/backend/nodes/outfuncs.c
src/backend/nodes/read.c
src/test/regress/expected/bit.out
src/test/regress/sql/bit.sql