Adjust bytea get_bit/set_bit to use int8 not int4 for bit numbering.
Since the existing bit number argument can't exceed INT32_MAX, it's
not possible for these functions to manipulate bits beyond the first
256MB of a bytea value. Lift that restriction by redeclaring the
bit number arguments as int8 (which requires a catversion bump,
hence is not back-patchable).
The similarly-named functions for bit/varbit don't really have a
problem because we restrict those types to at most VARBITMAXLEN bits;
hence leave them alone.
While here, extend the encode/decode functions in utils/adt/encode.c
to allow dealing with values wider than 1GB. This is not a live bug
or restriction in current usage, because no input could be more than
1GB, and since none of the encoders can expand a string more than 4X,
the result size couldn't overflow uint32. But it might be desirable
to support more in future, so make the input length values size_t
and the potential-output-length values uint64.
Also add some test cases to improve the miserable code coverage
of these functions.
Movead Li, editorialized some by me; also reviewed by Ashutosh Bapat
Discussion: https://postgr.es/m/20200312115135445367128@highgo.ca
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/26a944cf29ba67bb49f42656dd2be98fe2485f5f
Modified Files
--------------
doc/src/sgml/func.sgml | 4 +-
src/backend/utils/adt/encode.c | 136 +++++++++++++++++++++-------------
src/backend/utils/adt/varlena.c | 39 ++++++----
src/include/catalog/catversion.h | 2 +-
src/include/catalog/pg_proc.dat | 4 +-
src/include/utils/builtins.h | 4 +-
src/test/regress/expected/strings.out | 76 +++++++++++++++++++
src/test/regress/sql/strings.sql | 23 ++++++
8 files changed, 217 insertions(+), 71 deletions(-)
