| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Handle MAXSTRLEN consistently |
| Date: | 2026-08-12 19:07:57 |
| Message-ID: | 2858569.1786561677@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> writes:
> Commit 23d9ad77181 added additional length checks for tsvector, but it
> is inconsistent at one place: most checks use toklen > MAXSTRLEN as
> the error condition, but array_to_tsvector uses >=. This causes a
> strange corner-case issue: we can convert a 2047 length lexeme to an
> array, as tsvector_to_array allows it, but we can't convert it back
> with array_to_tsvector as it errors out.
> 0001 is a fix for this specific case.
> After looking into this further, I realized that the length handling
> is also inconsistent at other places, even before the mentioned
> commit.
Yeah. I noticed this inconsistency while preparing 23d9ad771,
but felt that fixing it was out of scope for a security patch.
There's a similar problem with inconsistent enforcement of
MAXSTRPOS. Attached is what I had staged to propose post-release.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Consistently-enforce-tsvector-tsquery-maximum-len.patch | text/x-diff | 4.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-08-12 19:18:20 | Re: hashjoins vs. Bloom filters (yet again) |
| Previous Message | Sami Imseih | 2026-08-12 18:33:20 | Re: problems with toast.* reloptions |