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