| From: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | [PATCH] set_byte() with a count argument |
| Date: | 2026-09-21 12:22:46 |
| Message-ID: | CAH7T-apJx4QJ8wqQuq8gY1Ov6Wg4pVyTTa+ZNCQ4Qt3xNj2khQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| Attachment | Content-Type | Size |
|---|---|---|
| 0002-Add-set_byte-bytea-int-int-int-to-set-a-range-of-byt.patch | text/x-patch | 9.8 KB |
| 0001-Reject-out-of-range-newvalue-in-set_byte.patch | text/x-patch | 3.0 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-09-21 12:31:39 | Re: Logical replication can lose an update after concurrent index invalidation |
| Previous Message | Rıdvan Korkmaz | 2026-09-21 12:21:56 | pg_resetwal with replication slot (17.11) |