Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> 1) rename FULLTEXT to TEXT SEARCH in SQL command
> Working on it, I found rather obvious undesired side-effect: if TEXT
> becomes a keyword then any output of name of text type becomes
> quoted. Even if TEXT is in unreserved_keyword list.
Yeah, I was
Go ahead and make the changes you want, and then I'll work on this.
So, I'm planing on this weekend:
1) rename FULLTEXT to TEXT SEARCH in SQL command
2) rework Snowball stemmer's as Tom suggested
3) ALTER FULLTEXT CONFIGURATION cfgname ADD/ALTER/DROP MAPPING
4) remove support of default configur
danish, dutch, finnish, french, german, hungarian, italian, norwegian,
portuguese, spanish, swedish, russin and english
Albe Laurenz wrote:
Tom Lane wrote:
Teodor Sigaev <[EMAIL PROTECTED]> writes:
So, it's needed to change dictinitoption format of snowball
dictionaries to
point both stop-w
Tom Lane wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> So, it's needed to change dictinitoption format of snowball
dictionaries to
>> point both stop-word file and language's name.
>
> Right.
Is there any chance to get support for other languages than English and
Russian into the tsearch
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> I splited stemmers to two sets because of regression test. As I
> remember, there was some problems with loadable conversions and
> configure's flag --disable-shared
I'm not worried about supporting --disable-shared installations very
much. They didn't
I've done some more work on this point. After looking at the Snowball
code in more detail, I'm thinking it'd be a good idea to keep it at
arm's length in a loadable shared library, instead of incorporating it
I splited stemmers to two sets because of regression test. As I remember, there
was s
I wrote:
> Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> 2 Snowball's compiling infrastructure doesn't support Windows target.
> Yeah. Another problem with using their original source code is that
> running the Snowball compiler during build would not work for
> cross-compiled builds of Postgres,
Teodor Sigaev <[EMAIL PROTECTED]> writes:
> 2 Snowball's compiling infrastructure doesn't support Windows target.
Yeah. Another problem with using their original source code is that
running the Snowball compiler during build would not work for
cross-compiled builds of Postgres, at least not witho
1 Compiling from .sbl by original Snowball's makefile requires Perl and
doesn't work cleanly:
AFAIK, you don't receive any answers on your email in snowball mailing list.
2 Snowball's compiling infrastructure doesn't support Windows target.
3 I understand your wish about including only real s
This makes no difference in terms of the ease of tracking their changes,
of course, but it just feels better to me to be distributing "real"
source code and not derived files.
Hmm.
1 Compiling from .sbl by original Snowball's makefile requires Perl and doesn't
work cleanly:
% gmake
cc -o
Josh Berkus <[EMAIL PROTECTED]> writes:
>> Is there a reasonable way to treat libstemmer as an external library?
> Hmmm ... do we want to do that if we're distributing it in core? That
> would require us to have a --with-tsearch compile switch so that people
> who don't want to find & build lib
Tom,
> Is there a reasonable way to treat libstemmer as an external library?
Hmmm ... do we want to do that if we're distributing it in core? That
would require us to have a --with-tsearch compile switch so that people
who don't want to find & build libstemmer can build PostgreSQL. I thought
While looking at the tsearch-in-core patch I was distressed to notice
that a good fraction of it is derived files, bearing notices such as
/* This file was generated automatically by the Snowball to ANSI C compiler */
Our normal policy is "no derived files in CVS", so I went looking to
see if we
13 matches
Mail list logo
