| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | shihao zhong <zhong950419(at)gmail(dot)com> |
| Cc: | Manav Kumar <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-05 09:53:05 |
| Message-ID: | 57543781-5EDF-451B-A652-DEED9A3FD15A@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On 4 Nov 2026, at 22:05, shihao zhong <zhong950419(at)gmail(dot)com> wrote:
> > I'm sure it isn't weakening protections to handle a synthetic case.
>
> My original thought was that we already had a mechanism for messages
> over 30k, so why not just reuse it.
I see it the other way around, we have a protection against messages over 30k,
and that framing makes it unappealing here.
> 2. Limit the length in guc. A long value then fails with a normal guc
> error instead of a disconnect. I can do it in a check hook one by one
> or create a new mechanism to limit the size of string guc?
This is the only possibility IMHO. Is there a case where setting a longer
value than what SET allows will be useful for anything?
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Shlok Kyal | 2026-11-05 10:43:12 | Re: Streaming decoding fails with "unexpected table_index_fetch_tuple call during logical decoding" when a relation has a TOASTed conbin (follow-up to BUG #18641) |
| Previous Message | PG Bug reporting form | 2026-11-05 09:39:38 | BUG #19834: eager aggregation still evaluates volatile join clauses when the volatile function is inside a SubPl |