On Tue, Sep 22, 2026 at 5:55 AM Matthias van de Meent <[email protected]> wrote: > > On Mon, 21 Sept 2026 at 15:17, Sehrope Sarkuni <[email protected]> wrote: > > > > Yes, it's possible, but seems clunky and has the extra intermediate > > alloc for the repeat and decode: > > Right, but implementing a repeat() for bytea should remove the alloc > and memory scan of decode(), and (IMO) would be a more universally > useful addition.
I'll take a look at that separately as repeat(...) for bytea is definitely useful. > Do you have a workload in mind that would hit this operation hard > enough that the additional allocs (and function calls) becomes a > significant overhead, or other reasons why overlay's behaviour is > impractical for your workload? More the clunkiness than the allocs. I think the intent is clearer with the count arg. I was reading through some corruption validation patches and there was a lot of set_byte(set_byte(set_byte(...))) in the tests. Some of it was distinct values and overlay(...) was better fit. But a bunch were all the same value, hence the thought of the additional count arg for set_byte(...). > Note, I'm not a huge fan of a 'count' argument in set_byte, as the > function name implies a singular byte being set. I always thought of it like memset(...) so the count arg seems natural. I considered a separate set_bytes(...) but it'd duplicate set_byte(...) with a count of 1, so the optional arg seemed tidier. Regards, -- Sehrope Sarkuni Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
