Trevor Talbot wrote:
> 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.
Remember an expression index can be a user-created function so you can
embed whatever you want in your function and just index it's output,
just like you would with a trigger creating a separate column.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
