| From: | "Trevor Talbot" <quension(at)gmail(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>, "Teodor Sigaev" <teodor(at)sigaev(dot)ru> |
| Subject: | Re: text search vs schemas |
| Date: | 2007-08-18 09:38:42 |
| Message-ID: | 90bce5730708180238v172bd3c4xc63af8af0e25e32c@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 8/17/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> At the moment I feel our thoughts have to revolve not around adding
> complexity to tsearch, but taking stuff out. If we ship it with no
> schema support for TS objects in 8.3, we can always add that later,
> if there proves to be real demand for that (and I note that the contrib
> version has gotten along fine without it). But we cannot go in the
> other direction.
Currently you can schema-qualify objects where you need to, to avoid
issues with search_path subversion. If it's impossible to
schema-qualify tsearch configs now, when schema support is later added
it suddenly exposes everyone to risks that didn't exist before, and
requires manual changes to fix.
I'm for removing complexity, but per-schema support seems like a
design decision that needs to be made up front, whichever way it goes.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Trevor Talbot | 2007-08-18 10:22:58 | Re: tsearch2 in PostgreSQL 8.3? |
| Previous Message | Trevor Talbot | 2007-08-18 09:35:21 | Re: text search vs schemas |