Tighten data validity checks in tsvectorrecv(). Insist that the input lexemes be already sorted and non-duplicate. There's no good reason for them not to be, since the required ordering is simple and platform-independent. The previous coding was willing to re-sort them, but that left a gap: it didn't de-duplicate them. De-duplicating would potentially require merging position lists, which would be painful; we can't easily re-use tsvectorin()'s logic for that, since it uses a different temporary representation. Let's just dodge the problem by insisting the lexeme list be fully correct as-presented, as we were already doing for the position lists.
Also, there was an oversight in the position-list checking: it did not verify that the first position isn't zero. tsvectorin() rejects that, so this should too. While these problems allow tsvectorrecv() to construct tsvectors that would not be generated internally, the vectors aren't so broken that we can't work with them. Therefore, the best course of action seems to be to apply these tighter rules in master but not back-patch. Back-patching might break application workflows that aren't causing any serious problems. Any such users will need to clean their data before loading it into PG >= v20, but they'd face that issue anyway, and a major update is a better time for it than a minor update. Bug: #19748 Reported-by: Ke <[email protected]> Author: Tom Lane <[email protected]> Discussion: https://postgr.es/m/[email protected] Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/10cc5aa96a6df7cb1d7c47e978cc94f01f785cb7 Modified Files -------------- src/backend/utils/adt/tsvector.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
