Re: [HACKERS] text search vs schemas

2007-08-18 Thread Trevor Talbot
On 8/18/07, Tom Lane <[EMAIL PROTECTED]> wrote: > As my copy of the patch currently stands, there are two built-in trigger > functions, tsvector_update_trigger and tsvector_update_trigger_column. > The first expects trigger arguments > name of tsvector col, name of tsconfig to use, name(s) of

Re: [HACKERS] text search vs schemas

2007-08-18 Thread Tom Lane
"Trevor Talbot" <[EMAIL PROTECTED]> writes: > 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'

Re: [HACKERS] text search vs schemas

2007-08-18 Thread Trevor Talbot
On 8/17/07, Tom Lane <[EMAIL PROTECTED]> 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

Re: [HACKERS] text search vs schemas

2007-08-18 Thread Trevor Talbot
Tom Lane <[EMAIL PROTECTED]> wrote: > Gregory Stark <[EMAIL PROTECTED]> writes: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > >> Uh, no. Function names for example are subject to search-path > >> confusion. > > > Wait, are they? They are in PL languages but only because most > > languages store the

Re: [HACKERS] text search vs schemas

2007-08-17 Thread Tom Lane
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > On Fri, Aug 17, 2007 at 10:42:09AM -0400, Tom Lane wrote: >> If you insist on a solution that involves attaching type information >> to trigger arguments, then we can forget about getting tsearch into 8.3. > Hmm, maybe I didn't explain clearly e

Re: [HACKERS] text search vs schemas

2007-08-17 Thread Tom Lane
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Freitag, 17. August 2007 05:15 schrieb Tom Lane: >> Actually ... I'm suddenly not happy about the choice to put text search >> configurations etc. into schemas at all. > But that isn't different from any other part of the system. A proper fix > w

Re: [HACKERS] text search vs schemas

2007-08-17 Thread Martijn van Oosterhout
On Fri, Aug 17, 2007 at 10:42:09AM -0400, Tom Lane wrote: > Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > > I'm unsure how it works now, but it seems reasonable that when a > > regclass/regtype/regetc is passed to a trigger, pass it in OID form. > > If you insist on a solution that involves

Re: [HACKERS] text search vs schemas

2007-08-17 Thread Tom Lane
Martijn van Oosterhout <[EMAIL PROTECTED]> writes: > On Fri, Aug 17, 2007 at 01:16:22AM -0400, Tom Lane wrote: >> That seems like it'd fix the problem for expression indexes on >> to_tsvector calls, but I don't see how it fixes the problem for >> triggers. We don't have any clear path for making t

Re: [HACKERS] text search vs schemas

2007-08-17 Thread Peter Eisentraut
Am Freitag, 17. August 2007 05:15 schrieb Tom Lane: > 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

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Martijn van Oosterhout
On Fri, Aug 17, 2007 at 01:16:22AM -0400, Tom Lane wrote: > That seems like it'd fix the problem for expression indexes on > to_tsvector calls, but I don't see how it fixes the problem for > triggers. We don't have any clear path for making trigger arguments > be anything but a list of strings. I

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Oleg Bartunov
On Thu, 16 Aug 2007, Tom Lane wrote: 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 ar

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Tom Lane
Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> writes: >> Uh, no. Function names for example are subject to search-path >> confusion. > Wait, are they? They are in PL languages but only because most > languages store their source code as text just as is happening here.

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Gregory Stark
"Tom Lane" <[EMAIL PROTECTED]> writes: > "Trevor Talbot" <[EMAIL PROTECTED]> writes: >> Wouldn't treating them as actual objects remove this whole issue? > > Uh, no. Function names for example are subject to search-path > confusion. Wait, are they? They are in PL languages but only because most

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Tom Lane
"Trevor Talbot" <[EMAIL PROTECTED]> writes: > Wouldn't treating them as actual objects remove this whole issue? Uh, no. Function names for example are subject to search-path confusion. regards, tom lane ---(end of broadcast)---

Re: [HACKERS] text search vs schemas

2007-08-16 Thread Trevor Talbot
On 8/16/07, Tom Lane <[EMAIL PROTECTED]> 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 st

[HACKERS] text search vs schemas

2007-08-16 Thread Tom Lane
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