"Simon Riggs" <simon@2ndquadrant.com> writes:
> ISTM that the functional index would be considerably smaller than the
> additional column approach, since tsvectors can be quite long. That
> seems like a very desirable thing with larger textbases. However,
> without an additional column certain queries would not be possible, such
> as IndexScans on a non-text search index with an additional filter on
> text search. So each way would be desirable in different situations.
Huh? Of course you can do the searching without an additional column;
you just have to compute the tsvector on-the-fly at each row. This is
a straight trade of more CPU cycles for less I/O.
> Would it be wrong to allow both approaches?
Nobody has suggested disallowing the trigger approach (indeed it's hard
to see how we could). The argument is mostly about how to make a
functional index approach work conveniently; and secondarily about
what's needed to make dump/restore reliably reproduce the current
database state, whichever approach you choose.
regards, tom lane