public inbox for [email protected]help / color / mirror / Atom feed
Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard 9+ messages / 6 participants [nested] [flat]
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 14:35 Joshua D. Drake <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Joshua D. Drake @ 2006-08-02 14:35 UTC (permalink / raw) To: Devrim GUNDUZ <[email protected]>; +Cc: pgsql-www >> I'm trying to look up the SQL keyword 'in' using the postgresql.org web >> search function. Well isn't that interesting. He has a valid point. I think Tsearch can pick which words it won't ignore so we could take IN SELECT JOIN things like that out, however that would take changing our infrastructure. I did send an email to Oleg about whether or not they would let us use what pgsql.ru uses. I even offered to set it up all ourselves providing they offer some basic email feedback. No response thus far. Joshua D. Drake >> >> Unfortunately, this word is also present in about every third sentence of >> every page, making it impossible to search for. >> >> In fact, a lot of the sql keywords are impossible to search for, because >> they're lost in the noise. >> >> Can this be fixed? >> >> Thanks! >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 15:18 Dave Page <[email protected]> parent: Joshua D. Drake <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Dave Page @ 2006-08-02 15:18 UTC (permalink / raw) To: Joshua D. Drake <[email protected]>; Devrim GUNDUZ <[email protected]>; +Cc: pgsql-www > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Joshua D. Drake > Sent: 02 August 2006 15:35 > To: Devrim GUNDUZ > Cc: [email protected] > Subject: Re: [pgsql-www] [Fwd: [BUGS] BUG #2560: Web page > documentation hard > > > >> I'm trying to look up the SQL keyword 'in' using the > postgresql.org web > >> search function. > > Well isn't that interesting. He has a valid point. I think > Tsearch can > pick which words it won't ignore so we could take IN SELECT > JOIN things > like that out, however that would take changing our infrastructure. ASPSeek can as well (they're called stopwords) but it won't help in this case because even if we don't ignore IN et al. it'll still match virtually every page. Regards, Dave. ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 17:33 Robert Treat <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Robert Treat @ 2006-08-02 17:33 UTC (permalink / raw) To: pgsql-www; +Cc: Dave Page <[email protected]>; Joshua D. Drake <[email protected]>; Devrim GUNDUZ <[email protected]> On Wednesday 02 August 2006 11:18, Dave Page wrote: > > -----Original Message----- > > From: [email protected] > > [mailto:[email protected]] On Behalf Of Joshua D. Drake > > Sent: 02 August 2006 15:35 > > To: Devrim GUNDUZ > > Cc: [email protected] > > Subject: Re: [pgsql-www] [Fwd: [BUGS] BUG #2560: Web page > > documentation hard > > > > >> I'm trying to look up the SQL keyword 'in' using the > > > > postgresql.org web > > > > >> search function. > > > > Well isn't that interesting. He has a valid point. I think > > Tsearch can > > pick which words it won't ignore so we could take IN SELECT > > JOIN things > > like that out, however that would take changing our infrastructure. > > ASPSeek can as well (they're called stopwords) but it won't help in this > case because even if we don't ignore IN et al. it'll still match > virtually every page. > What would be nice would be to have a first level of human specified keywords that return specific information, above and beyond the general search. This could operate similarly to rtfm_please on irc or my rtfmbot on AIM. This way when someone searches on something like IN, we can say "you're probably looking for this --> link" If there are general search results, we could show them after the pre-spelected links. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 17:57 Robert Bernier <[email protected]> parent: Robert Treat <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Robert Bernier @ 2006-08-02 17:57 UTC (permalink / raw) To: pgsql-www On Wednesday 02 August 2006 13:33, Robert Treat wrote: > > ASPSeek can as well (they're called stopwords) but it won't help in this > > case because even if we don't ignore IN et al. it'll still match > > virtually every page. > > What would be nice would be to have a first level of human specified > keywords that return specific information, above and beyond the general > search. This could operate similarly to rtfm_please on irc or my rtfmbot > on AIM. This way when someone searches on something like IN, we can say > "you're probably looking for this --> link" If there are general search > results, we could show them after the pre-spelected links. Could a set of links be returned, somewhere on the page, that would always refer to one or more keywords when a single word is used as the search criteria? ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 19:12 Richard Huxton <[email protected]> parent: Robert Bernier <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Richard Huxton @ 2006-08-02 19:12 UTC (permalink / raw) To: Robert Bernier <[email protected]>; +Cc: pgsql-www Robert Bernier wrote: > On Wednesday 02 August 2006 13:33, Robert Treat wrote: >>> ASPSeek can as well (they're called stopwords) but it won't help in this >>> case because even if we don't ignore IN et al. it'll still match >>> virtually every page. >> What would be nice would be to have a first level of human specified >> keywords that return specific information, above and beyond the general >> search. This could operate similarly to rtfm_please on irc or my rtfmbot >> on AIM. This way when someone searches on something like IN, we can say >> "you're probably looking for this --> link" If there are general search >> results, we could show them after the pre-spelected links. > > > Could a set of links be returned, somewhere on the page, that would always > refer to one or more keywords when a single word is used as the search > criteria? Could we not just score the index more highly than other pages? http://www.postgresql.org/docs/8.1/static/bookindex.html -- Richard Huxton Archonet Ltd ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 19:29 Tom Lane <[email protected]> parent: Richard Huxton <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Tom Lane @ 2006-08-02 19:29 UTC (permalink / raw) To: Richard Huxton <[email protected]>; +Cc: Robert Bernier <[email protected]>; pgsql-www Richard Huxton <[email protected]> writes: > Robert Bernier wrote: >> On Wednesday 02 August 2006 13:33, Robert Treat wrote: >>> ASPSeek can as well (they're called stopwords) but it won't help in this >>> case because even if we don't ignore IN et al. it'll still match >>> virtually every page. > Could we not just score the index more highly than other pages? I don't think people want to be presented links to indexes; the search engine is supposed to keep them from having to use anything as low tech as an index, no? But what strikes me is the idea of teaching the search engine not to ignore stopwords that are marked as <indexterm>'s ... regards, tom lane ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 20:39 Dave Page <[email protected]> 0 siblings, 1 reply; 9+ messages in thread From: Dave Page @ 2006-08-02 20:39 UTC (permalink / raw) To: Tom Lane <[email protected]>; Richard Huxton <[email protected]>; +Cc: Robert Bernier <[email protected]>; pgsql-www -----Original Message----- From: "Tom Lane" <[email protected]> To: "Richard Huxton" <[email protected]> Cc: "Robert Bernier" <[email protected]>; "[email protected]" <[email protected]> Sent: 02/08/06 20:30 Subject: Re: [pgsql-www] [Fwd: [BUGS] BUG #2560: Web page documentation hard > 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. Regards, Dave ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 20:43 Tom Lane <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Tom Lane @ 2006-08-02 20:43 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Richard Huxton <[email protected]>; Robert Bernier <[email protected]>; pgsql-www "Dave Page" <[email protected]> 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 ^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard @ 2006-08-02 21:33 Dave Page <[email protected]> 0 siblings, 0 replies; 9+ messages in thread From: Dave Page @ 2006-08-02 21:33 UTC (permalink / raw) To: Tom Lane <[email protected]>; Dave Page <[email protected]>; +Cc: Richard Huxton <[email protected]>; Robert Bernier <[email protected]>; pgsql-www -----Original Message----- From: "Tom Lane" <[email protected]> To: "Dave Page" <[email protected]> Cc: "Richard Huxton" <[email protected]>; "Robert Bernier" <[email protected]>; "[email protected]" <[email protected]> Sent: 02/08/06 21:43 Subject: Re: [pgsql-www] [Fwd: [BUGS] BUG #2560: Web page documentation hard > 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. The website is HTML, not SGML - there are no <indexterm>'s to teach the indexer about. Regards, Dave ^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2006-08-02 21:33 UTC | newest] Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2006-08-02 14:35 Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Joshua D. Drake <[email protected]> 2006-08-02 15:18 ` Dave Page <[email protected]> 2006-08-02 17:33 ` Robert Treat <[email protected]> 2006-08-02 17:57 ` Robert Bernier <[email protected]> 2006-08-02 19:12 ` Richard Huxton <[email protected]> 2006-08-02 19:29 ` Tom Lane <[email protected]> 2006-08-02 20:39 Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Dave Page <[email protected]> 2006-08-02 20:43 ` Tom Lane <[email protected]> 2006-08-02 21:33 Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Dave Page <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox