BUG #17691: Unexpected behaviour using ts_headline()
От | PG Bug reporting form |
---|---|
Тема | BUG #17691: Unexpected behaviour using ts_headline() |
Дата | |
Msg-id | 17691-93cef39a14663963@postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #17691: Unexpected behaviour using ts_headline()
Re: BUG #17691: Unexpected behaviour using ts_headline() Re: BUG #17691: Unexpected behaviour using ts_headline() |
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 17691 Logged by: Sebastian Patino-Lang Email address: sebastian.patino-lang@posteo.net PostgreSQL version: 13.9 Operating system: x86_64-apple-darwin19.6.0 Description: I experience unexpected behaviour when using ts_headline() in general, but especially when changing MaxFragments. Given the data in ts_headline_report.sql [1] SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Highlight word is the first one in the result. Expectation: highlight word is somewhere in the middle. id=2: No highlight word at all. id=3: Highlight words are the first and last one in the result. Not ideal but ok-ish. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=1, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Highlight word is now in the middle of the result. This is ok. id=2: No highlight word at all. id=3: Highlight words are in the middle part of the result. This is ok. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=2, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Correct number of fragments (2) with highlight words are returned. id=2: No highlight word at all. id=3: Correct number of fragments (2) with highlight words are returned. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=3, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Wrong number of fragments (2) with highlight words are returned. id=2: No highlight word at all. id=3: Correct number of fragments (3) with highlight words are returned. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=4, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Wrong number of fragments (2) with highlight words are returned. id=2: No highlight word at all. id=3: Correct number of fragments (4) with highlight words are returned. ... and so on. Until MaxFragments=6 where for id=1 suddenly more fragments (4) get returned. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=4, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Wrong number of fragments (4) with highlight words are returned. id=2: No highlight word at all. id=3: Correct number of fragments (6) with highlight words are returned. ... and so on. Until MaxFragments=11 where for id=1 the number of returned fragments changes again (5) SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=11, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Wrong number of fragments (5) with highlight words are returned. id=2: No highlight word at all. id=3: Correct number of fragments (11) with highlight words are returned. ... and so on. Until MaxFragments=14 where for id=2 suddenly more fragments (2) get returned. SELECT id, ts_headline('english', "texts"."fulltext", to_tsquery('english', 'amazon & world'), 'MaxFragments=14, StartSel=<<, StopSel=>>') AS "preview" FROM texts; id=1: Wrong number of fragments (5) with highlight words are returned. id=2: Wrong number of fragments (2) with highlight words are returned. id=3: Correct number of fragments (11) with highlight words are returned. I stopped testing here, but im sure the strange behaviour and jumps in fragment count will continue. Any ideas? [1] https://1drv.ms/u/s!AqRGi9iGBWddgZVU_M2iuoRdTzM6tg?e=0OHHnB
В списке pgsql-bugs по дате отправления:
Предыдущее
От: "David G. Johnston"Дата:
Сообщение: Re: BUG #17689: Two UPDATE operators in common table expressions (CTE) perform not as expected