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 <[email protected]> Reviewed-by: Zsolt Parragi <[email protected]> Discussion: https://postgr.es/m/can4czfnyqo4zfbrr435ud0vsfuy5y7dnfoxdfkr9zyol1jn...@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(-)
