Re: Make tsqueryout() use a StringInfo

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

In response to

Responses

Browse pgsql-hackers by date

  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