| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Make tsqueryout() use a StringInfo |
| Date: | 2026-08-16 17:10:33 |
| Message-ID: | CAJTYsWVC5ajxoME3q0A55VYvUaJWMzLwHF3Lai7rkRjcFqrW-w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, 13 Aug 2026 at 21:16, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> While doing the recent security work on tsvector/tsquery overflows,
> I wondered why tsqueryout() is using its very own hand-rolled
> implementation of an extensible string buffer, rather than using
> StringInfo like the rest of the backend. I couldn't see any actual
> bug there, so changing it was out of scope for a security fix.
> But it seems fragile and hard to read, so here's a patch to make it
> use StringInfo.
>
Thanks for the patch!
The patch looks good to me in general. One thing I wonder about is the
increase in the initial allocation: the old code starts with 32 bytes,
whereas initStringInfo() starts with 1024 bytes. ig this can add up when
tsqueryout() is called by array_out(), since array_out() retains each
element's output string while constructing the result?
Would it make sense to use initStringInfoExt(&nrm.buf, 32) here, preserving
the old initial size while retaining automatic growth?
Regards,
Ayush
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-08-16 17:38:21 | Residual cleanups for tied objects in PL/Perl |
| Previous Message | mailinglists | 2026-08-16 16:48:48 | pg_upgrade from pg19 source build to pg19-beta3 throws an error |