On 8/16/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
That assumes a database-oriented search config, instead of a case of
multiple users confined to invidual schemas doing their own thing. Is
the latter possible now, and do you want to remove that ability?
Something else that occurs to me though: the problem seems to be that
parts of tsearch take object names as strings. I thought one
advantage of having it in core is that they are now real database
objects, with owners etc. How many other database objects are passed
around as string labels?
Wouldn't treating them as actual objects remove this whole issue?
What happens now if you try to drop a configuration that's still used
in a trigger somewhere?
(I'm new to both tsearch2 and this list, so please excuse any
mistakes. Mostly keeping an eye on this for future use in my own
projects.)