Re: tsearch_core for inclusion - Mailing list pgsql-hackers

From Florian G. Pflug
Subject Re: tsearch_core for inclusion
Date
Msg-id 45FAC4EF.4080109@phlo.org
Whole thread Raw
In response to Re: tsearch_core for inclusion  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Oleg Bartunov wrote:
> On Fri, 16 Mar 2007, Joshua D. Drake wrote:
> 
>>
>>> One a related note - will to_tsvector and to_tsquery be renamed to
>>> something like ft_parse_text() and ft_parse_query() if tsearch2 goes
>>
>> Furthering this... perhaps even:
>>
>> ft_search()
>> ft_query()
> 
> ts_ means Text Search, I don't think ft_ (Full Text) is better.
> Going further it should be fts_ (Full Text Search), but we have many 
> concerns about compatibility and stability of api, so I'd prefer
> to stay with ts_.

Hm, so it could be fts_parse_query() and fts_parse_text()
You could alias it to to_tsvector() and to_tsquery() to
archive api compatibility.

I agree that the names of these functions are really a minor
issue, and api compatibility is more important. But confusing
names can be the source of a lot of errors for new users, so
there *is* a point is naming things consistenly. And if the
cost is basically an entry in pg_proc, why not do it?

greetings, Florian Pflug




pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: tsearch_core for inclusion
Next
From: "Pavan Deolasee"
Date:
Subject: Re: Question: pg_class attributes and race conditions ?