[PATCH] set_byte() with a count argument

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

Responses

Browse pgsql-hackers by date

  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)