To: Tom Lane
> Cc: Hackers
> Subject: Re: [HACKERS] Full Text Indexing
>
>
> > "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > > I'm playing around with the Full Text Indexing module, and I
> notice that
> > > it's case-sensitive.
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > I'm playing around with the Full Text Indexing module, and I notice that
> > it's case-sensitive. This seems to be pretty useless to me -
> especially for
> > my application. I wonder if there'd be any objections to me
> modifying it to
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I'm playing around with the Full Text Indexing module, and I notice that
> it's case-sensitive. This seems to be pretty useless to me - especially for
> my application. I wonder if there'd be any objections to me modifying it to
> be case-i
Hi,
I'm playing around with the Full Text Indexing module, and I notice that
it's case-sensitive. This seems to be pretty useless to me - especially for
my application. I wonder if there'd be any objections to me modifying it to
be case-insensitive. Or at least be configurable either way...
A
At 10:52 AM 11/28/00 +0100, Magnus Hagander wrote:
>> > b) Check out MSSQL 7's capabilities and weep.
>>
>> BTW, have you studied MSSQL enough to tell me if it has a
>> separate/standalone
>> (as a process) fti engine or just another index type.
>It is standalone - separate process, data is sto
> > b) Check out MSSQL 7's capabilities and weep.
>
> BTW, have you studied MSSQL enough to tell me if it has a
> separate/standalone
> (as a process) fti engine or just another index type.
It is standalone - separate process, data is stored in separate files (not
in db).
In SQL Server 7.0, yo
john huttley wrote:
>
> > I believe that it is appropriate for contrib/ because it is a good demo
> > of FTI-like capabilities. But nothing more, yet. For at least a couple
> > of reasons:
> >
> > 1) It generates the "index" as a table, not a PostgreSQL index or
> > index-like thing.
> >
> > 2) I
> I believe that it is appropriate for contrib/ because it is a good demo
> of FTI-like capabilities. But nothing more, yet. For at least a couple
> of reasons:
>
> 1) It generates the "index" as a table, not a PostgreSQL index or
> index-like thing.
>
> 2) It has a hardcoded list of non-indexed
> > OK, can someone collect suggestions, add the code, and integrate it for
> > 7.1?
>
> too late in cycle ...
How about first thing for 7.2 then? While it lies in limbo,
its never going to get the attention it deserves.
Regards
[ Charset ISO-8859-1 unsupported, converting... ]
> I modified the FTI trigger for my own use a while ago (indexes whole
> words, eliminates duplicate a few other things) -- I'm not sure if it would
> do anyone any good but you're welcome to it. To whom should I send it?
Is full-word optional
> > > Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> > > tree?' would be more productive on that front.
> > Well, yes. Why isn't it?
I believe that it is appropriate for contrib/ because it is a good demo
of FTI-like capabilities. But nothing more, yet. For at least a cou
At 11:06 PM 11/27/00 -0400, The Hermit Hacker wrote:
>On Mon, 27 Nov 2000, Bruce Momjian wrote:
>> OK, can someone collect suggestions, add the code, and integrate it for
>> 7.1?
>
>too late in cycle ...
Yes...
- Don Baccus, Portland OR <[EMAIL PROTECTED]>
Nature photos, on-line guides, Pa
Hacker" <[EMAIL PROTECTED]>
To: "Bruce Momjian" <[EMAIL PROTECTED]>
Cc: "Don Baccus" <[EMAIL PROTECTED]>; "John Huttley" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Monday, November 27, 2000 7:06 PM
Subject: Re: [HACKERS] Full text Index
On Mon, 27 Nov 2000, Bruce Momjian wrote:
> > >Well, yes. Why isn't it?
> > >
> > >Full text indexing should be just as much a feature as any other key feature in
> > >PG.
> > >With the advent of unlimited file and record lengths in 7.1, this would be a good
> > >time to
> > >include it.
> > >
>
> >Well, yes. Why isn't it?
> >
> >Full text indexing should be just as much a feature as any other key feature in
> >PG.
> >With the advent of unlimited file and record lengths in 7.1, this would be a good
> >time to
> >include it.
> >
> >FTI is particularly useful in the context of web content e
John Huttley wrote:
> > Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> > tree?' would be more productive on that front.
> Well, yes. Why isn't it?
I'm hoping to see the answer to that one myself, as that is outside my
scope currently. I just RPMize things... Although,
At 02:51 PM 11/28/00 +1300, John Huttley wrote:
>>
>> Maybe asking 'Why isn't the contrib full-text-indexer not in the main
>> tree?' would be more productive on that front.
>
>Well, yes. Why isn't it?
>
>Full text indexing should be just as much a feature as any other key feature in
>PG.
>With th
>
> Maybe asking 'Why isn't the contrib full-text-indexer not in the main
> tree?' would be more productive on that front.
Well, yes. Why isn't it?
Full text indexing should be just as much a feature as any other key feature in
PG.
With the advent of unlimited file and record lengths in 7.1, thi
John Huttley wrote:
> Would you please consider bringing the contributed package into the
> official distribution.
> I found that trying to compile it with the RedHat RPM based installation
> was a monumental pain. I gave up.
> Its useful, people ask about it on the list, so why not?
If there
Would you please consider bringing the contributed package into the
official distribution.
I found that trying to compile it with the RedHat RPM based installation
was a monumental pain. I gave up.
Its useful, people ask about it on the list, so why not?
For comparison, checkout what MSSQL 7 c
Andrew McMillan <[EMAIL PROTECTED]> writes:
>
> I would _love_ to see full-text or keyword indexing natively in
> PostgreSQL.
>
I would rather love to see a great fulltext engine integrated with
PostgreSQL. It would be cool to be able to have ranked results and
different ways of searching the i
Andrew McMillan wrote:
>
> Bruce Momjian wrote:
> >
> > See contrib/fulltextindex.
>
> An easy answer, but not a very good solution in the real world.
>
> contrib/fulltextindex requires you to jump through hoops in developing
> queries to retrieve your data. It's also very space-inefficient in
Bruce Momjian wrote:
>
> See contrib/fulltextindex.
An easy answer, but not a very good solution in the real world.
contrib/fulltextindex requires you to jump through hoops in developing
queries to retrieve your data. It's also very space-inefficient in that
a table with a fulltextindex on a f
See contrib/fulltextindex.
[ Charset ISO-8859-1 unsupported, converting... ]
> I didn't see any mention of it on the TODO so I thought I'd ask if anyone
> had thought about full test indexing for 7.1 (I'm guessing not)..
>
> If not, I'd like to suggest it be put on the TODO -- if nothing else so
I didn't see any mention of it on the TODO so I thought I'd ask if anyone
had thought about full test indexing for 7.1 (I'm guessing not)..
If not, I'd like to suggest it be put on the TODO -- if nothing else so
someone could pick it up in the far future if they wanted to.. It doesn't
seem like t
25 matches
Mail list logo
