From: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: tsearch in core patch, for inclusion |
Date: | 2007-01-25 16:06:16 |
Message-ID: | 45B8D578.7070808@sigaev.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
> 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 & AGAINST which 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(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2007-01-25 16:10:53 | Re: crash on 8.2 and cvshead - failed to add item to the |
Previous Message | Joshua D. Drake | 2007-01-25 16:04:49 | Re: [HACKERS] how to plan for vacuum? |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-01-25 16:11:06 | Re: Getting rid of warnings |
Previous Message | Tom Lane | 2007-01-25 15:57:29 | Re: Getting rid of warnings |