Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 09FBA475AE4 for ; Tue, 15 Oct 2002 10:07:12 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id 2C73C475ADD for ; Tue, 15 Oct 2002 10:07:11 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g9FE7FhR014678; Tue, 15 Oct 2002 10:07:15 -0400 (EDT) To: Brian Blaha Cc: pgsql-sql@postgresql.org Subject: Re: SQL function triggers In-reply-to: <3DABB04B.8000104@umr.edu> References: <3DABB04B.8000104@umr.edu> Comments: In-reply-to Brian Blaha message dated "Tue, 15 Oct 2002 06:06:03 -0000" Date: Tue, 15 Oct 2002 10:07:14 -0400 Message-ID: <14677.1034690834@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200210/162 X-Sequence-Number: 9879 Brian Blaha writes: > I would like to write a function as a set of SQL statements, and then > use that function > in a trigger. However, since triggers require a return type of opaque, > and SQL functions > cannot return type opaque, this doesn't look possible. You could call a SQL function from a trigger, but it can't be a trigger itself; at present triggers have to be in C, plpgsql, or pltcl (maybe plpython? Not sure about that one). For what you are doing (transferring info from one table to another) I suspect a rule might work better than a trigger anyway. regards, tom lane