Re: Proposal: syntax of operation with tsearch's configuration

Alvaro Herrera wrote:
> Oleg Bartunov wrote:
>> On Fri, 17 Nov 2006, Andrew Dunstan wrote:
> 
>>> 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.
>> this looks reasonable to me.
> 
> Huh, but we don't use keywords with ugly abbreviations and underscores.
> How about "FULLTEXT DICTIONARY" and "FULLTEXT PARSER"?  (Using
> "FULLTEXT" instead of "FULL TEXT" means you don't created common
> reserved words, and furthermore you don't collide with an existing type
> name.)

sounds fine

> 
> I also think the "thousands of lines" is an exaggeration :-)  The
> grammar should take a couple dozen at most.  The rest of the code would
> go to their own files.
> 
> We should also take the opportunity to discuss new keywords for the XML
> support -- will we use new grammar, or functions?
> 

that is a good question and we should decide on a direction for that -
we already have a feature in shipping code that causes quite some
confusion in that regard(autovacuum).
What see I from supporting/consulting people is that there are more and
more people adapting autovacuum for there databases but those with
complex ones want to override them on a per table base.
We already provide a rather crude interface for that - namely manually
inserting some rows into a system table which is confusing the heck out
of people (they are either responding with "why is there now ALTER
AUTOVACUUM SET ..." or and equivalent pg_* function for that).
I'm not too sure what the most suitable interface for that would be but
finding a consistent solution for that might be good nevertheless.


Stefan