| From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
|---|---|
| To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
| Cc: | "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: tsearch_core for inclusion |
| Date: | 2007-03-16 16:25:19 |
| Message-ID: | 45FAC4EF.4080109@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2007-03-16 16:26:56 | Re: Question: pg_class attributes and race conditions ? |
| Previous Message | Stefan Kaltenbrunner | 2007-03-16 16:18:55 | Re: tsearch_core for inclusion |