We can't put tsvector_update_trigger() into core in anything like its
current form. As is, it will take an unqualified function name, look
it up, and call it. The prospects for subversion by search path
manipulation are obvious, and even if you aren't concerned about
malicious attacks, the effects of the trigger are context-dependent
(and maybe time-varying; it doesn't insist on the function being
immutable) in exactly the same way that we've been saying we can't
accept for the tsearch configuration.
I think we should redefine the trigger as taking trigger arguments that
are first a config name, then a list of one or more field names, and
nothing else.
People who want extra processing done on their fields before forming the
tsvector can write custom triggers to do it ...
regards, tom lane