Re: Stored Procedure / Trigger Strangeness
От | laotse@lumberjack.snurgle.org |
---|---|
Тема | Re: Stored Procedure / Trigger Strangeness |
Дата | |
Msg-id | Pine.LNX.4.41.0112211046270.28797-100000@lumberjack.snurgle.org обсуждение исходный текст |
Ответ на | Re: Stored Procedure / Trigger Strangeness (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
I'll try passing multiple column names and see how that does. If that does not work, I could write a plpgsql function that gets called first with all the arguments and then calls fti multiple times, once for each keyword, I suppose. ----------------------------------------------------------------------------- Brian Knox Just Another Perl Hacker perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR!AUBGNSTY];print' On Fri, 21 Dec 2001, Tom Lane wrote: > laotse@lumberjack.snurgle.org writes: > > ------------------------------------------------------------------ CREATE > > TRIGGER fti_employee_lastname AFTER UPDATE OR INSERT OR DELETE ON person > > FOR EACH ROW EXECUTE PROCEDURE fti(fti, lastname); > > > CREATE TRIGGER fti_employee_firstname AFTER UPDATE OR INSERT OR DELETE ON > > person FOR EACH ROW EXECUTE PROCEDURE fti(fti, firstname); > > > CREATE TRIGGER fti_employee_screenname AFTER UPDATE OR INSERT OR DELETE ON > > person FOR EACH ROW EXECUTE PROCEDURE fti(fti, screenname); > > This will not work because there's no guarantee about the order of the > execution of the triggers. I haven't worked with fti much, but it's > obvious that it expects you to have only *one* trigger relating a given > indextable to the master --- on update, the trigger deletes all existing > indextable rows for that master row. > > It looks like the intended way to index multiple columns using a single > indextable is > > CREATE TRIGGER fti_person AFTER UPDATE OR INSERT OR DELETE ON person > FOR EACH ROW EXECUTE PROCEDURE fti(fti, firstname, lastname, screenname); > > Or you could use a separate indextable for each column, but that might > not be what you want. > > regards, tom lane >
В списке pgsql-general по дате отправления: