| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal: syntax of operation with tsearch's configuration |
| Date: | 2006-11-17 18:43:04 |
| Message-ID: | 455E02B8.8020104@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Teodor Sigaev wrote:
> Hmm, IMHO, it's needed for consistent interface: nobody adds new
> column to table by editing pg_class & pg_attribute, nobody looks for
> description of table by selection values from system table.
>
>
> Tom Lane wrote:
>> Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>>> Now we (Oleg and me) are working on moving tsearch into core.
>>> Pls, review suggested syntax. Comments, suggestions, objections will
>>> be appreciated.
>>
>> Is it really necessary to invent a batch of special-purpose commands?
>> Seems like this will add some thousands of lines of code and no actual
>> new functionality; not to mention loss of backwards compatibility for
>> existing tsearch2 users.
>>
>>
>
Thousands of lines seems a high estimate, but maybe I'm wrong. I guess
an alternative would be to do this in some builtin functions, but that
seems a tad unclean.
I am also a bit concerned that the names of the proposed objects
(parser, dictionary) don't convey their purpose adequately. Maybe
TS_DICTIONARY and TS_PARSER might be better if we in fact need to name them.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2006-11-17 19:28:49 | Re: Proposal: syntax of operation with tsearch's configuration |
| Previous Message | Teodor Sigaev | 2006-11-17 18:09:34 | Re: Proposal: syntax of operation with tsearch's configuration |