public inbox for [email protected]
help / color / mirror / Atom feed[Fwd: [BUGS] BUG #2560: Web page documentation hard to use]
10+ messages / 9 participants
[nested] [flat]
* [Fwd: [BUGS] BUG #2560: Web page documentation hard to use]
@ 2006-08-02 13:53 Devrim GUNDUZ <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Devrim GUNDUZ @ 2006-08-02 13:53 UTC (permalink / raw)
To: pgsql-www
-------- Forwarded Message --------
> From: PFudd <[email protected]>
> To: [email protected]
> 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: [email protected]
> 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/
Attachments:
[application/pgp-signature] signature.asc (189B, 2-signature.asc)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard
@ 2006-08-02 14:35 Joshua D. Drake <[email protected]>
parent: Devrim GUNDUZ <[email protected]>
0 siblings, 1 reply; 10+ 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] 10+ 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; 10+ 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] 10+ 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, 2 replies; 10+ 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] 10+ 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]>
1 sibling, 1 reply; 10+ 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] 10+ 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, 2 replies; 10+ 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] 10+ messages in thread
* latin-1 to utf8 in python
@ 2006-08-02 19:26 anil maran <[email protected]>
parent: Richard Huxton <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: anil maran @ 2006-08-02 19:26 UTC (permalink / raw)
To: pgsql-www
postgres takes utf8
pls help me solve this thanks a lot
some data is in latin-1 so postgres
crashes
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', '[email protected]'])
"); //-->
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
^ permalink raw reply [nested|flat] 10+ 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]>
1 sibling, 0 replies; 10+ 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] 10+ messages in thread
* Re: [Fwd: [BUGS] BUG #2560: Web page documentation
@ 2006-08-02 21:53 Dave Page <[email protected]>
parent: Robert Treat <[email protected]>
1 sibling, 0 replies; 10+ messages in thread
From: Dave Page @ 2006-08-02 21:53 UTC (permalink / raw)
To: Robert Treat <[email protected]>; pgsql-www; +Cc: Joshua D. Drake <[email protected]>; Devrim GUNDUZ <[email protected]>
On 2/8/06 18:33, "Robert Treat" <[email protected]> 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
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: latin-1 to utf8 in python
@ 2006-08-03 07:06 Tino Wildenhain <[email protected]>
parent: anil maran <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Tino Wildenhain @ 2006-08-03 07:06 UTC (permalink / raw)
To: anil maran <[email protected]>; +Cc: pgsql-www
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/thr...;])
>
> <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
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2006-08-03 07:06 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-08-02 13:53 [Fwd: [BUGS] BUG #2560: Web page documentation hard to use] Devrim GUNDUZ <[email protected]>
2006-08-02 14:35 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Joshua D. Drake <[email protected]>
2006-08-02 15:18 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Dave Page <[email protected]>
2006-08-02 17:33 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Robert Treat <[email protected]>
2006-08-02 17:57 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Robert Bernier <[email protected]>
2006-08-02 19:12 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Richard Huxton <[email protected]>
2006-08-02 19:26 ` latin-1 to utf8 in python anil maran <[email protected]>
2006-08-03 07:06 ` Re: latin-1 to utf8 in python Tino Wildenhain <[email protected]>
2006-08-02 19:29 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation hard Tom Lane <[email protected]>
2006-08-02 21:53 ` Re: [Fwd: [BUGS] BUG #2560: Web page documentation 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