Re: Tsearch vs Snowball, or what's a source file?
От | Tom Lane |
---|---|
Тема | Re: Tsearch vs Snowball, or what's a source file? |
Дата | |
Msg-id | 27912.1180823335@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Tsearch vs Snowball, or what's a source file? (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Tsearch vs Snowball, or what's a source file?
|
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> 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 libstemmer can build PostgreSQL. I thought > the whole point of this feature was to have a version of Tsearch which > "just worked" for users. True. I just noticed that the upstream master distribution (their compiler source and .sbl files) weighs in at half the size of the libstemmer distribution: 68K vs 129K in tar.gz format --- no doubt due to all the repetitive boilerplate in the generated files. I'm not sure if the compiler source has any portability issues, but if not it is interesting to consider the idea of bundling the master distro instead of libstemmer. This would fix at least one issue that we otherwise will have, which is that the #include-paths they chose to generate libstemmer with seem a bit unfriendly for our purposes. The #include commands are determined by compiler options, so we could fix them if compiling the .sbl files on the fly. 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. regards, tom lane
В списке pgsql-hackers по дате отправления: