Re: set_config(‘search_path’) does not truncate names over 63 bytes, unlike SET

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: daniel(at)yesql(dot)se
Cc: mkumar(at)yugabyte(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: set_config(‘search_path’) does not truncate names over 63 bytes, unlike SET
Date: 2026-11-08 02:18:52
Message-ID: CAGRkXqTHBo7ND0+8k-rpb3QMC=9wx3fPtWprF24FvNabhd0t8Q@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Daniel,

> This is the only possibility IMHO. Is there a case where setting a
> longer value than what SET allows will be useful for anything?

I don't think so. A schema name over 63 bytes is never useful, since
the lookup only uses the first 63 bytes. But SET truncates each name,
not the list. A SET search_path with 500 names of 63 bytes is about
32kB, and it drops the connection the same way. So a limit per name is
not enough.

So 3 changes in the 0001
1. It limits every GUC_REPORT because extension can use this flag to
shoot themself in their foot.
2. It handles client -> server encoding conversion by
MAX_CONVERSION_GROWTH
3. Move the magic number 30000 to a #define.

0002 is an optional test.

Thanks,
Shihao

Attachment Content-Type Size
v2-0001-Limit-the-length-of-reported-string-GUCs.patch application/octet-stream 4.5 KB
v2-0002-Add-a-test-for-the-search_path-length-limit.patch application/octet-stream 3.1 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message shihao zhong 2026-11-08 03:06:37 Re: BUG #19788: Chinese translation uses incorrect term for “transaction” in “no transaction is in progress”
Previous Message shihao zhong 2026-11-08 01:30:18 Re: BUG #19644: byteaout, float8out and float4out are marked IMMUTABLE but depend on GUCs