Skip site navigation (1) Skip section navigation (2)

Re: FUNCTION, TRIGGER and best practices

From: Michael Fuhr <mike(at)fuhr(dot)org>
To: Keith Worthington <keithw(at)narrowpathinc(dot)com>
Cc: PostgreSQL Novice <pgsql-novice(at)postgresql(dot)org>
Subject: Re: FUNCTION, TRIGGER and best practices
Date: 2004-12-17 06:52:09
Message-ID: 20041217065209.GA32514@winnie.fuhr.org (view raw or flat)
Thread:
Lists: pgsql-novicepgsql-sql
On Thu, Dec 16, 2004 at 11:05:20PM -0500, Keith Worthington wrote:

> Can triggers and functions have the same name?

The "Trigger Procedures" section of the "PL/pgSQL - SQL Procedural
Language" chapter in the documentation shows a trigger having the
same name as the function it calls.  And you could always try it.

> Is this a good practice?

I'd suggest using whatever names seem the most self-documenting for
a particular application.  Maybe somebody else will present arguments
advocating one style or another; I don't have strong opinions either
way.

Multiple triggers on a table will fire alphabetically by trigger
name, so firing order might affect how you name the triggers.

> Where should the function and trigger be stored?
> In the same schema as the table they are connected to?

If objects (functions, types, etc.) are dedicated to tables in a
particular schema then I usually create them in that schema to keep
everything together.  That can be handy for doing backups with
"pg_dump --schema schemaname".

> I will now be attempting to expand this function to move data from two source
> tables to four or more target tables.  (Different source columns go to
> different tables.)  Is it possible to do a transaction/commit/rollback inside
> a function that is driven by a trigger so that if any portion of the transfer
> fails it is all rolled back?

See the last paragraph of the "Structure of PL/pgSQL" section in
the "PL/pgSQL - SQL Procedural Language" chapter of the documentation,
as well as the "Errors and Messages" section in the same chapter.
Functions can't execute COMMIT or ROLLBACK, but they can raise an
exception to abort the current transaction.  In PostgreSQL 8.0
functions can trap errors, effectively allowing you to have a
subtransaction inside your function.  See "Trapping Errors" in the
"Control Structures" documentation for details.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/

In response to

pgsql-novice by date

Next:From: Steve TucknottDate: 2004-12-17 07:48:12
Subject: Reading across databases
Previous:From: Josh BerkusDate: 2004-12-17 05:43:32
Subject: Re: FUNCTION, TRIGGER and best practices

pgsql-sql by date

Next:From: Marcus ClaessonDate: 2004-12-17 09:46:45
Subject: can't get the order I want after inserting new rows
Previous:From: Richard Sydney-SmithDate: 2004-12-17 06:23:32
Subject: Table History

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group