Oleg Bartunov <oleg@sai.msu.su> writes:
> On Thu, 16 Aug 2007, Josh Berkus wrote:
>> First off, I'll assert that backup/restore is a serious issue and while the
>> folks who want Tsearch in core now are dismissing it, we'll be fielding the
>> complaints later. Any solution which involves setting a GUC at restore time
>> *which could vary per table or even column* isn't acceptable.
> Josh, all my respects to you, but text searching is not about index at all.
> Text searching is about tsvector and tsquery data type
What's your point? The problem is just as bad for an auto-update
trigger that computes a stored tsvector column. If the trigger's
behavior depends on the GUC settings of the person doing an insert,
things will soon be a mess --- do you really want the tsvector contents
to change after an update of an unrelated field? After awhile you
won't have any idea what's really in the column, because you won't
have any good way to know which rows' tsvectors were generated with
which configurations.
Even if that state of affairs is really what you want, reproducing
it after a dump/reload will be tricky. I think that a regular
schema-and-data dump would work, because pg_dump doesn't install
triggers until after it's loaded the data ... but a data-only dump
would *not* work, because the trigger would fire while loading rows.
Basically I see no use for a setup in which the configuration used
for a particular tsvector value is not fully determined by the table
definition. Whether the value is in an index or in the table proper
is irrelevant to this argument.
regards, tom lane
