From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | text search vs schemas |
Date: | 2007-08-17 03:15:28 |
Message-ID: | 26985.1187320528@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Trevor Talbot | 2007-08-17 03:46:14 | Re: text search vs schemas |
Previous Message | Joshua D. Drake | 2007-08-17 02:29:01 | Re: GIT patch |