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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org