On Wed, 2007-06-13 at 18:06 -0400, Bruce Momjian wrote:
> You bring up a very good point. There are fifteen new commands being
> added for full text indexing:
>
> alter-fulltext-config.sgml alter-fulltext-owner.sgml
> create-fulltext-dict.sgml drop-fulltext-dict.sgml
> alter-fulltext-dict.sgml alter-fulltext-parser.sgml
> create-fulltext-map.sgml drop-fulltext-map.sgml
> alter-fulltext-dictset.sgml comment-fulltext.sgml
> create-fulltext-parser.sgml drop-fulltext-parser.sgml
> alter-fulltext-map.sgml create-fulltext-config.sgml
> drop-fulltext-config.sgml
Although I'm happy to see tsearch finally hit the big time, I'm a bit
disappointed to see so many new datatype-specific SQL commands created.
That sets a bad precedent for other datatype authors, as well as all
those people that want to invent new things like SKYLINE etc..
Whatever the reasons for the new commands, those reasons must also be
potentially shared by authors of other datatypes too. Is there a way to
genericise these commands so that we can offer those same benefits to
all datatypes, rather than setting a double standard? Or do we think
that when a Geodetic datatype tries to come into core we would have
commands like CREATE COORDINATE TRANSFORM?
Can we consider CREATE TYPE CONFIGURATION with subsets such as...
CREATE TYPE CONFIGURATION name USING FULLTEXT (map)
CREATE TYPE CONFIGURATION name USING FULLTEXT (dictionary)
CREATE TYPE CONFIGURATION name USING FULLTEXT (parser)
Your choice of syntax may vary, but my point is about creating a
mechanism by which any datatype author can reference complex
configuration details. We managed to do this for INDEXes and OPERATORs,
so it seems a shame to go for the full 15 new commands when we could do
the same thing with much fewer commands and ones that could then be
utilised by others, e.g. PostGIS.
Last minute change true, but only parser+docs changes suggested. I want
the full tsearch2 functionality as much as anyone.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
