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
"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'
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
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
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
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
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
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
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
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
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
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.
"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
"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)---
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
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
16 matches
Mail list logo