Re: tsearch in core patch, for inclusion

> This is a fairly large patch and I would like the chance to review it
> before it goes in --- "we'll commit tomorrow" is not exactly a decent
> review window.
Not a problem.

> One possible argument for this over the contrib version is a saner
> approach to dumping and restoring configurations.  However, as against
> that:
> 
> 1) what's the upgrade path for getting an existing tsearch2
> configuration into this implementation?

It's should clear enough for now - dump data from old db and load into new one. 
But dump should be without any contrib/tsearch2 related functions.

> 
> 2) once we put this in core we are going to be stuck with supporting its
> SQL API forever.  Are we convinced that this API is the one we want?
> I don't recall even having seen any proposal or discussion.  It was OK
> for tsearch2's API to change every release while it was in contrib, but
> the expectation of stability is a whole lot higher for core features.

Basic tsearch2 SQL API doesn't changed since its first release, just extended. 
As I can see, there isn't any standard of fulltext search in SQL. DB/2, MS SQL, 
Oracle and MySQL use different SQL API. I don't know which better. I remember 
only one suggestion: 'CREATE FULLTEXT INDEX ...'. So, I believe, existing SQL 
API satisfies users. But it possible to emulate on grammar level subset of MySQL
syntax:
SQL commands
CREATE FULLTEXT INDEX idxname ON tbl [ USING {GIN|GIST} ] ( field1[, [...]] );
SELECT .. FROM table WHERE MATCH( field1[, [...]] ) AGAINST ( txt );

will be translated to
CREATE INDEX idxname ON tbl [ USING {GIN|GIST} ] ( to_tsquery(field1)[ || [...]] );
SELECT .. FROM table WHERE ( to_tsquery(field1)[ || [...]] ) @@ plainto_tsquery( 
txt );
 Notes  1 that is full equivalent MySQL's MATCH() AGAINST (txt IN BOOLEAN MODE)  2 it requires to keyword MATCH &
AGAINSTwhich cannot be a function's name    without quoting.
 

Internal API changed sometimes (not every release), but I don't see a problem 
here: all other internal API's in postgres are often changed.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
  WWW: http://www.sigaev.ru/