pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Consistently enforce tsvector/tsquery maximum lengths. 7+ messages / 1 participants [nested] [flat]
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1fc1b82b2fe1011565a157bc660eceab60ed7923 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/957d4eae52eccbfb949fa043ae07527a69bcbcf6 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/b42d0c310bec31073cf523a99caf5c79abf9e204 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/5185e64ae0b220fac434f10a490bf108f01cb66a Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/ef9063a8870fb5fb1666da3399ff666201eccf70 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a68beda425a0471230f39ef9852d5dffc38ee7c1 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Consistently enforce tsvector/tsquery maximum lengths. @ 2026-08-13 15:20 Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 7+ messages in thread From: Tom Lane @ 2026-08-13 15:20 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Consistently enforce tsvector/tsquery maximum lengths. Some places rejected individual tokens longer than MAXSTRLEN, while others rejected ones longer than MAXSTRLEN-1. The data structure is perfectly capable of handling MAXSTRLEN, so there's nothing wrong with using the looser bound. Moreover, as things stand there is a dump/reload hazard: some code paths permit construction of a tsvector or tsquery that would later be rejected by tsvectorin or tsqueryin. So standardize on using MAXSTRLEN. Identical remarks apply to MAXSTRPOS (the total data length), so fix that too. Back-patch, in hopes of avoiding cases where a value acceptable to one supported release is not acceptable to another. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Zsolt Parragi <zsolt.parragi@percona.com> Discussion: https://postgr.es/m/CAN4CZFNYQo4zfbRR435uD0vSfuy5y7dnFOXDfKr9zYoL1JnAxA@mail.gmail.com Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/39cad0de4ac3a6d211e1ad00bc1af061a753b414 Modified Files -------------- src/backend/tsearch/ts_parse.c | 4 ++-- src/backend/utils/adt/tsquery.c | 6 +++--- src/backend/utils/adt/tsvector.c | 4 ++-- src/backend/utils/adt/tsvector_op.c | 4 ++-- 4 files changed, 9 insertions(+), 9 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-08-13 15:20 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us> 2026-08-13 15:20 pgsql: Consistently enforce tsvector/tsquery maximum lengths. Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox