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.


                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [EMAIL PROTECTED] so that your
       message can get through to the mailing list cleanly

Reply via email to