A couple of tsearch loose ends - Mailing list pgsql-hackers

From Tom Lane
Subject A couple of tsearch loose ends
Date
Msg-id 4242.1187715144@sss.pgh.pa.us
Whole thread Raw
Responses Re: A couple of tsearch loose ends  ("Pavel Stehule" <pavel.stehule@gmail.com>)
Re: A couple of tsearch loose ends  (Teodor Sigaev <teodor@sigaev.ru>)
Re: A couple of tsearch loose ends  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
There are a couple of naming issues that I left untouched while
reviewing the tsearch patch, but wanted to bring up for discussion.

One thing that had me confused for awhile is that the patch uses
the word "template" in two different ways.  The main use is that a
"template" is an object encapsulating the superuser-only aspects of
defining a dictionary.  When you do CREATE TEXT SEARCH DICTIONARY
you have to specify a template to base it on.  So in this context
a dictionary and its template are different kinds of objects, and
there's a persistent connection between them.

On the other hand, CREATE TEXT SEARCH CONFIGURATION also uses the
word "template", but in this case it's an optional specification
of an existing configuration that gets copied.  So here, the config
and the template are the same kind of object, and there's no
connection between them after the copy is made.

This seems a bit confusing, and I wonder whether we ought not
change the terminology for one thing or the other.  I don't
particularly want to rename text search templates ... that would
be quite a bit of work at this point ... so what I'd suggest is
that the option to CREATE TEXT SEARCH CONFIGURATION be renamed
"COPY" instead of "TEMPLATE".  Another thought here is that I'm
inclined to drop the "with map" option and just always copy the
source configuration exactly.  If you don't want the map, the
only other information the source can provide is a parser name,
which you might as well just give directly.

The other thing that was bugging me was that a lot of the dictionary
types have init options that are named things like DictFile, AffFile,
etc.  As I mentioned before, I dislike the fact that these things are
out in the filesystem rather than inside the database, and hope that
that will change eventually.  So I think that these names are not
future-proof and should be altered to not use the word "file";
especially so in view of the fact that as committed, the patch doesn't
let you specify a path name for them.  I already did that to StopFile,
which is now StopWords, but did not touch the other dictionary options.
I'm not sure what to do with DictFile, because that doesn't seem to have
any special meaning at all once you take out "file" ...

Comments?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: tsearch2 patch status report
Next
From: Tom Lane
Date:
Subject: Re: tsearch2 patch status report