Thread: [Fwd: [BUGS] BUG #2560: Web page documentation hard to use]
-------- Forwarded Message -------- > From: PFudd <kernel@pkts.ca> > To: pgsql-bugs@postgresql.org > Subject: [BUGS] BUG #2560: Web page documentation hard to use > Date: Tue, 1 Aug 2006 16:54:03 GMT > > The following bug has been logged online: > > Bug reference: 2560 > Logged by: PFudd > Email address: kernel@pkts.ca > PostgreSQL version: 8.1.4 > Operating system: N/A > Description: Web page documentation hard to use > Details: > > I'm trying to look up the SQL keyword 'in' using the postgresql.org web > search function. > > 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. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Attachment
>> 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/
> -----Original Message----- > From: pgsql-www-owner@postgresql.org > [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Joshua D. Drake > Sent: 02 August 2006 15:35 > To: Devrim GUNDUZ > Cc: pgsql-www@postgresql.org > 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.
On Wednesday 02 August 2006 11:18, Dave Page wrote:
> > -----Original Message-----
> > From: pgsql-www-owner@postgresql.org
> > [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Joshua D. Drake
> > Sent: 02 August 2006 15:35
> > To: Devrim GUNDUZ
> > Cc: pgsql-www@postgresql.org
> > 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
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?
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
postgres takes utf8
pls help me solve this thanks a lot
some data is in latin-1 so postgres
crashes
with
crashes
with
psycopg2.ProgrammingError at /todo/38
invalid byte sequence for encoding "UTF8": 0x92
invalid byte sequence for encoding "UTF8": 0x92
ariable Value
args
("INSERT INTO xdaad(nt, nn, tadadid, email) VALUES (%s, %s, %s, %s); SELECT
currval('comments_id_seq')", ['co-worker\x92snd I\x92ll get the .\r\n\r\n \r\n\r\nAeF\r\n\r\n\r\n\r\n \r\n\r\n', '121', '38', '...@tad.com'])
args
("INSERT INTO xdaad(nt, nn, tadadid, email) VALUES (%s, %s, %s, %s); SELECT
currval('comments_id_seq')", ['co-worker\x92snd I\x92ll get the .\r\n\r\n \r\n\r\nAeF\r\n\r\n\r\n\r\n \r\n\r\n', '121', '38', '...@tad.com'])
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Richard Huxton <dev@archonet.com> 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
On 2/8/06 18:33, "Robert Treat" <xzilla@users.sourceforge.net> wrote:
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.
Nice idea. It would mean hacking search.cgi to add an appropriate search of a set of links and to add it to the template system. Not trivial, but certainly not impossible.
Got time? And no, it’s C, not Ruby :-p
Regards, Dave
anil maran schrieb:
> postgres takes utf8
> pls help me solve this thanks a lot
> some data is in latin-1 so postgres
> crashes
hm. "crashes" isnt quite correct, it
would "bark" or something, however ;)
> with
> psycopg2.ProgrammingError at /todo/38
> invalid byte sequence for encoding "UTF8": 0x92
> ariable Value
> args
> ("INSERT INTO xdaad(nt, nn, tadadid, email) VALUES (%s, %s, %s, %s); SELECT
> currval('comments_id_seq')", ['co-worker\x92snd I\x92ll get the
> .\r\n\r\n \r\n\r\nAeF\r\n\r\n\r\n\r\n \r\n\r\n', '121', '38', '...
>
<http://groups.google.com/groups/unlock?msg=ead2077185e3de4c&_done=/group/webpy/browse_thread/thread/22297f1549fc41b2/ead2077185e3de4c>@tad.com'])
>
> <http://groups.google.com/group/webpy/browse_thread/thread/22297f1549fc41b2/ead2077185e3de4c#>
Well you either recode in python:
latin1string.decode('iso-8859-1').encode('utf-8')
or set your client-encoding for postgres, so
postgres does the conversion.
Look into psycopg api how to do this on connect
or just issue:
"SET CLIENT_ENCODING TO 'iso-8859-1'"
just after connect.
Regards
Tino Wildenhain