Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M312714=pgsql-hackers-arkari@postgresql.org>)
	id 1cIMKc-0006Bq-9w
	for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Dec 2016 21:15:50 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
	by malur.postgresql.org with smtp (Exim 4.84_2)
	(envelope-from
 <pgsql-hackers-owner+M312714=pgsql-hackers-arkari@postgresql.org>)
	id 1cIMKb-00032C-3B
	for pgsql-hackers@arkaria.postgresql.org; Sat, 17 Dec 2016 21:15:49 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1cIMKZ-00030r-98
	for pgsql-hackers@postgresql.org; Sat, 17 Dec 2016 21:15:47 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1cIMKR-0000bl-O2
	for pgsql-hackers@postgresql.org; Sat, 17 Dec 2016 21:15:46 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id uBHLFbb2018848
	for <pgsql-hackers@postgresql.org>; Sat, 17 Dec 2016 16:15:38 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgresql.org
Subject: Re: Rethinking our fulltext phrase-search implementation
In-reply-to: <28215.1481999808@sss.pgh.pa.us>
References: <28215.1481999808@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Sat, 17 Dec 2016 13:36:48 -0500"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <18770.1482009263.0@sss.pgh.pa.us>
Date: Sat, 17 Dec 2016 16:15:37 -0500
Message-ID: <18847.1482009337@sss.pgh.pa.us>
X-Pg-Spam-Score: -5.0 (-----)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <18770.1482009263.1@sss.pgh.pa.us>

I wrote:
> It's worth noting that with these rules, phrase searches will act as
> though "!x" always matches somewhere; for instance "!a <-> !b" will match
> any tsvector.  I argue that this is not wrong, not even if the tsvector is
> empty: there could have been adjacent stopwords matching !a and !b in the
> original text.  Since we've adjusted the phrase matching rules to treat
> stopwords as unknown-but-present words in a phrase, I think this is
> consistent.  It's also pretty hard to assert this is wrong and at the same
> time accept "!a <-> b" matching b at the start of the document.

To clarify this point, I'm imagining that the patch would include
documentation changes like the attached.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff; name="ts-doc-changes.patch"; charset="us-ascii"
Content-ID: <18770.1482009263.2@sss.pgh.pa.us>
Content-Description: ts-doc-changes.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/doc/src/sgml/datatype.sgml b/doc/src/sgml/datatype.sgml
index 67d0c34..464ce83 100644
*** a/doc/src/sgml/datatype.sgml
--- b/doc/src/sgml/datatype.sgml
*************** SELECT 'fat &amp; rat &amp; ! cat'::tsqu
*** 3959,3973 ****
          tsquery=20=20=20=20=20=20=20=20=20
  ------------------------
   'fat' &amp; 'rat' &amp; !'cat'
-=20
- SELECT '(fat | rat) &lt;-&gt; cat'::tsquery;
-               tsquery
- -----------------------------------
-  'fat' &lt;-&gt; 'cat' | 'rat' &lt;-&gt; 'cat'
  </programlisting>
-=20
-      The last example demonstrates that <type>tsquery</type> sometimes
-      rearranges nested operators into a logically equivalent formulation.
      </para>
=20=20
      <para>
--- 3959,3965 ----
diff --git a/doc/src/sgml/textsearch.sgml b/doc/src/sgml/textsearch.sgml
index 2da7595..bc33a70 100644
*** a/doc/src/sgml/textsearch.sgml
--- b/doc/src/sgml/textsearch.sgml
*************** text @@ text
*** 323,328 ****
--- 323,330 ----
      at least one of its arguments must appear, while the <literal>!</> (N=
OT)
      operator specifies that its argument must <emphasis>not</> appear in
      order to have a match.
+     For example, the query <literal>fat &amp; ! rat</> matches documents =
that
+     contain <literal>fat</> but not <literal>rat</>.
     </para>
=20=20
     <para>
*************** SELECT phraseto_tsquery('the cats ate th
*** 377,382 ****
--- 379,401 ----
      then <literal>&amp;</literal>, then <literal>&lt;-&gt;</literal>,
      and <literal>!</literal> most tightly.
     </para>
+=20
+    <para>
+     It's worth noticing that the AND/OR/NOT operators mean something subt=
ly
+     different when they are within the arguments of a FOLLOWED BY operator
+     than when they are not, because then the position of the match is
+     significant.  Normally, <literal>!x</> matches only documents that do=
 not
+     contain <literal>x</> anywhere.  But <literal>x &lt;-&gt; !y</>
+     matches <literal>x</> if it is not immediately followed by <literal>y=
</>;
+     an occurrence of <literal>y</> elsewhere in the document does not pre=
vent
+     a match.  Another example is that <literal>x &amp; y</> normally only
+     requires that <literal>x</> and <literal>y</> both appear somewhere i=
n the
+     document, but <literal>(x &amp; y) &lt;-&gt; z</> requires <literal>x=
</>
+     and <literal>y</> to match at the same place, immediately before
+     a <literal>z</>.  Thus this query behaves differently from <literal>x
+     &lt;-&gt; z &amp; y &lt;-&gt; z</>, which would match a document
+     containing two separate sequences <literal>x z</> and <literal>y z</>.
+    </para>
    </sect2>
=20=20
    <sect2 id=3D"textsearch-intro-configurations">

------- =_aaaaaaaaaa0
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

------- =_aaaaaaaaaa0--