Digging through the simple vs advanced user discussion, I don't think
expression indexes are really the right idea. It seems a bit fragile,
you need a certain amount of knowledge about the optimizer to figure
out if your queries can even use the index, and it's just plain ugly.
It also seems like the choice is between either simple one-column
stuff, or triggers.
There are already several CREATE FULLTEXT items, so what if you take
it a bit farther:
CREATE TABLE posts (title text, body text);
CREATE FULLTEXT INDEX posts_fti ON posts (title WEIGHT A, body) CONFIG
english USING GIN;
..with searches looking something like..
... WHERE plainto_tsquery('...') @@ posts_fti ...
Okay, maybe that's not quite the right search abstraction (is it an
index or a column?), but you get the idea.
The point is that it would be fairly straightforward to do the common
things, and it works for people whose needs can be met with a "full
text index" rather than a "multidimensional search for lexemes" (or
whatever tsvector + index really is). The configuration is clearly
defined and stable, but queries can still use a GUC default.
Meanwhile all the current functions, types and operators are there for
use with triggers etc for advanced setups.
There's obviously a lot of detail missing, but if something like this
is the goal, then there doesn't need to be as much concern about
simple interfaces for 8.3, as long as the framework is ok. In
particular, expression indexes don't necessarily need special work
now.
It's a thought.
