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

On 11/17/06, Peter Eisentraut <peter_e@gmx.net> wrote:
> Alvaro Herrera wrote:
> > We should also take the opportunity to discuss new keywords for the
> > XML support -- will we use new grammar, or functions?
>
> The XML stuff is defined in the SQL standard and there are existing
> implementations, so any nonstandard syntax is going to be significantly
> less useful.  (The other problem is that you can't implement most of
> the stuff in functions anyway.)

Yes, it's better not to mix XML syntax discussion and the Tsearch2
configuration syntax discussion in one place. Not only because these
are different things - here we have a discussion of syntax for catalog
manipulation commands, when XML stuff (at least that I was working on
during summer and am going to continue) is about functionality itself.
And in case of XML we have some things to stick to - the standard
papers and existent implementations...

However, Alvaro made me to recall my old thoughts - when I just
started to use Tsearch2 I was wondering why should I explicitly create
column for index - in other databases I shouldn't do this. Indeed,
this is the index and, ideally, all I have to do is to write "CREATE
INDEX ..." only, maybe with some custom (fulltext-special) additions
(and something like "fulltext" instead of "gist").

So, is it possible to let people to avoid explicit "ALTER TABLE .. ADD
COLUMN ... tsvector"? Maybe it would be a "syntax sugar" too, but I
suppose that (especially for postgres-novices) it would simplify the
overall use of Tsearch. For me such changes are more important than
syntax for manipulations with catalog (i.e., I would live with "insert
into ts_cfg ..." one or two years more :-) ). However, I'm sure that
Oleg and Teodor already considered this feature and there should be
some things that prevent from letting users write only "CREATE INDEX"
w/o ALTERing tables...


>
> I don't see any comparable arguments about this full-text search stuff.
> In particular I don't see any arguments why a change would necessary at
> all, including why moving to core would be necessary in the first
> place.

Many hosters with PostgreSQL support (e.g. goDaddy - one of the
biggest hosters) don't provide any contrib module - so people have to
live w/o fulltext search. Then, many sysadmins are afraid of the word
"contrib"... So, there is no doubt for me that adding to core is
really good thing :-)

-- 
Best regards,
Nikolay