I wrote:
> 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
Actually ... I'm suddenly not happy about the choice to put text search
configurations etc. into schemas at all. We've been sitting here and
assuming that to_tsvector('english', my_text_col) has a well defined
meaning --- but as the patch stands, *it does not*. The interpretation
of the config name could easily change depending on search_path.
It does not seem likely that a typical installation will have so many
text search configs that subdividing them into schemas will really be
useful. If I recall correctly, Teodor did that on my recommendation
that it'd be the cleanest way to distinguish built-in from non-built-in
objects for dump purposes. That is, pg_dump would ignore TS objects
that are in pg_catalog and dump everything else. But I'm having severe
second thoughts about that.
What seems the most attractive alternative at the moment is to have a
flat namespace for TS objects (no schemas) and introduce something like
a "bool is_built_in" column for pg_dump to consult in deciding whether
to dump 'em.
Comments?
regards, tom lane
