Neil Conway wrote:
> On Wed, 2007-01-24 at 13:49 -0500, Tom Lane wrote:
>> 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.
>
> There has been some prior discussion:
>
> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00919.php
>
> But I agree that we need considerably more discussion before committing
> the patch. I'm personally not sold on the need for modifications to the
> SQL grammar, for example, as opposed to just using a set of SQL-callable
> functions and some new system catalogs.
I think one can find arguments for both variants - one of the question
might even be how other databases are doing that and if the proposed
syntax is resembling one of those or not.
>
> Another question that would be easier to resolve before the patch is
> committed is naming: the patch currently uses a mix of "full text" and
> "tsearch[2]" as the name of the full-text search feature. If we're going
> to bless this as "the" integrated full-text search in PG, it might make
> more sense to use "full text search" and "FTS" exclusively.
making this consistent makes a lot of sense and I agree that it might be
a good idea to just call it FTS (or similiar).
But on the other side would have to go as far as renaming
TSVECTOR/TSQUERY to FTSVECTOR/FTSQUERY or similiar which might pose some
considerable headache for people upgrading from the contrib/ version.
Stefan
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
