Re: tsearch_core for inclusion

On Fri, 16 Mar 2007, Magnus Hagander wrote:

>>> Most people whom I talk to about tsearch who want the syntax changed to make
>>> it easier want something akin to just "CREATE INDEX fti1 on t1(c1) USING
>>> FULLTEXT" and then be done with it.  This patch isn't going to give people
>>> that.
>>
>> Since we use standard postgresql-ish CREATE INDEX command, I assume
>> people want to skip creation of tsvector column ?
>
> That would be great.
>
>> How they could manage
>> complex document indexing, when document is a combination (with different weights)
>> of many text attributes from several tables, for example ?
>
> Just to give you some more work, could I have both, please.
>
> Seriously, if the current powerful functionality could be combined with a dead simple solution for new users and those who don't need it, that would be very
> good.
>
> This could be an auto generated hidden column or something, as long as the user doesn't need to see or care about it in the simple case.

hmm, then we should think about very generic fts configuration behind such
simple solution. We need to know what requirements and features should
be supported. for example, "CREATE INDEX fti1 on t1(c1) USING FULLTEXT"
syntax assume default configuration only.

Joshua, Tome proposed something like
CREATE INDEX fti1 on t1(c1) USING FULLTEXT [WITH] GIST | GIN,
so is't worth to extend it to specify fts configuration like
CREATE INDEX fti1 on t1(c1) USING FULLTEXT [public.pg]  [WITH] GIST | GIN 
Normally, fts configuration is used when creating tsvector, so 
CREATE INDEX doesn't need to know it. Hmm, looks rather messy.


	Regards,		Oleg
_____________________________________________________________
Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru),
Sternberg Astronomical Institute, Moscow University, Russia
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(495)939-16-83, +007(495)939-23-83