Hi hackers,
0002 adds a four-argument set_byte():
set_byte(bytes bytea, n integer, newvalue integer, count integer)
setting count consecutive bytes from byte n to newvalue:
SELECT set_byte('\x0000000000'::bytea, 1, 255, 3);
=> \x00ffffff00
Today this needs nested set_byte() calls, each copying the whole
value. The new form does one copy and one memset().
The result keeps the input's length. count < 0 is an error. A range
past the end is an error. count = 0 returns the input unchanged and
allows n = length. Because of that, the index error reports 0..length
when count is 0 and 0..length-1 if non-zero.
0001 is a separate fix. set_byte() never checked newvalue. It just
stored the low byte, so 256 sets \x00 and -1 sets \xff. Both forms now
reject values outside 0..255, as set_bit() does for its bit. I don't
think it should be backpatched.
Docs and tests included and make check passes with each patch applied.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/