On Thu, 15 Mar 2007, Robert Treat wrote:
On Thursday 15 March 2007 12:17, Teodor Sigaev wrote:
Last try there was a fight about syntax of introduced commands. And we
(Oleg and me) developed variant of patch with another syntax. We will not
change docs until agreement will be reached, current version
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/
Following demonstrates subset of FTS syntax using example from
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/fts-complete-tut.html.
This is nice.
<snip>
Comparing that syntaxes with current tsearch2 is placed at
http://mira.sai.msu.su/~megera/pgsql/ftsdoc/fts-syntax-compare.html
So, which is syntax more attractive?
Honestly I don't find any of these syntax's to be head and shoulders above the
others, but would probably lean toward the original syntax, since it has some
level of familiarity among the existing user base.
And is there some another objections?
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 ? How they could manage
complex document indexing, when document is a combination (with different
weights)
of many text attributes from several tables, for example ? There are several
other issues with that approach, for example, we need to store positional
information somewhere for ranking information. It's awkward to parse document
every time to get this information.
I'm also concerned about the stability of the tsearch api in general wrt
including it in core. Currently the recommended upgrade practice is to
dump/reload without tsearch, installing the new servers version of tsearch
instead. IMHO this is not an acceptable solution for core-included features.
So is this actually going to be improved in a core tsearch? system tables
are not dumped by default, so that seems easier, until you consider that your
custom tsearch install will then be lost on upgrade... oops!
This is exact reason why we want to include tsearch into core, it was discussed
several times.
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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
