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 ---------------------------(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