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: | Raw Message | Whole Thread | 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 |