X-Original-To: pgsql-www-postgresql.org@postgresql.org
Received: from localhost (wm.hub.org [200.46.204.128])
	by postgresql.org (Postfix) with ESMTP id 7644F9FB22A
	for <pgsql-www-postgresql.org@postgresql.org>;
	Wed,  2 Aug 2006 17:43:23 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024)
	with ESMTP id 34028-03 for <pgsql-www-postgresql.org@postgresql.org>;
	Wed,  2 Aug 2006 20:43:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 395F49FB21E
	for <pgsql-www@postgresql.org>; Wed,  2 Aug 2006 17:43:11 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k72Kh9Np020422;
	Wed, 2 Aug 2006 16:43:09 -0400 (EDT)
To: "Dave Page" <dpage@vale-housing.co.uk>
cc: "Richard Huxton" <dev@archonet.com>,
	"Robert Bernier" <robert.bernier5@sympatico.ca>, pgsql-www@postgresql.org
Subject: Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard 
In-reply-to: <013101c6b673$bbad9700$6a01a8c0@valehousing.co.uk> 
References: <013101c6b673$bbad9700$6a01a8c0@valehousing.co.uk>
Comments: In-reply-to "Dave Page" <dpage@vale-housing.co.uk>
	message dated "Wed, 02 Aug 2006 21:39:57 +0100"
Date: Wed, 02 Aug 2006 16:43:09 -0400
Message-ID: <20421.1154551389@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=3.816 tagged_above=0 required=5
	tests=SPF_HELO_SOFTFAIL, SPF_SOFTFAIL
X-Spam-Level: ***
X-Archive-Number: 200608/18
X-Sequence-Number: 10409

"Dave Page" <dpage@vale-housing.co.uk> writes:
>> But what strikes me is the idea of teaching the search engine not to
>> ignore stopwords that are marked as <indexterm>'s ...

> We tell it what to ignore, not the other way round. Besides, the problem as I understood it was that a search for 'IN' returns virtually every page (as one might expect) which is little help when looking for IN the keyword.

Right, so half of the problem is that IN should be considered a stopword
and isn't.  But after we fix that, it won't be found anywhere.  I
suggest that we want the search to find the pages on which IN (or any
other stopword) appears as an <indexterm>, and not elsewhere.

			regards, tom lane