From: Tom Lane <tgl@sss.pgh.pa.us>
To: esemmano@gmail.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18479: websearch_to_tsquery inconsistent behavior for german
 when using parentheses
In-reply-to: <2130969.1718316260@sss.pgh.pa.us>
References: <18479-d9b46e2fc242c33e@postgresql.org>
 <2130969.1718316260@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 13 Jun 2024 18:04:20 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2184369.1718323162.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Jun 2024 19:59:22 -0400
Message-ID: <2184370.1718323162@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2184370.1718323162%40sss.pgh.pa.us>
Precedence: bulk

[ couldn't let go of this ... ]

I wrote:
> It's fairly confusing that this code manages to ignore not-ISOPERATOR
> punctuation.  It seems like that gets eaten by gettoken_tsvector()
> and then later we decide there's not really a word there.

Yeah, further investigation shows that such cases effectively act
like stopwords: they are passed back to makepol() as VAL strings,
but then lexize processing rejects them as not words.

> I'm also confused how come the same thing doesn't happen in the
> english tsconfig.  Not sure it's worth poking at more, though.

D'oh: "or" is a stopword in the english config.  The english case
is still wrong of course, just differently:

regression=3D# select websearch_to_tsquery('english', 'foo or (baz bar) or=
 (ding dong)');
          websearch_to_tsquery           =

-----------------------------------------
 'foo' | 'baz' & 'bar' & 'ding' & 'dong'
(1 row)

			regards, tom lane