Tom Lane 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 > (and maybe time-varying; it doesn't insist on the function being > immutable) in exactly the same way that we've been saying we can't > accept for the tsearch configuration. > > I think we should redefine the trigger as taking trigger arguments that > are first a config name, then a list of one or more field names, and > nothing else. > > People who want extra processing done on their fields before forming the > tsvector can write custom triggers to do it ...
Agreed. A stated in email I didn't like the filter API on style grounds. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
