Subject: Update timestamp on update

From: Jeff Williams <[email-masked]>
Date: Thu, 13 Oct 2005 09:12:34 +0800

I have a table like:

CREATE TABLE products (
    id int,
    status int,
    last_status_change timestamp DEFAULT now()
);

What I would like is that whenever the status is changed the
last_status_change timestamp is updated to the current time. I have had
a look at the rules and what I want would be similar to:

CREATE RULE last_status_change AS ON UPDATE
    TO products WHERE NEW.status <> OLD.status
    DO UPDATE products SET last_status_change = now() WHERE id = OLD.id;

Except of course that the above is recursive and doesn't work.

How can I do this?

Jeff

---

From: Tom Lane <[email-masked]>
Date: Wed, 12 Oct 2005 21:44:49 -0400

> last_status_change timestamp is updated to the current time.

For this you use an ON UPDATE trigger; rules are not a good way to solve
it.  See the documentation about triggers.  The first example on this
page does it along with a few other things:
http://developer.postgresql.org/docs/postgres/plpgsql-trigger.html

			regards, tom lane

---

From: Jeff Williams <[email-masked]>
Date: Thu, 13 Oct 2005 10:42:06 +0800

>http://developer.postgresql.org/docs/postgres/plpgsql-trigger.html
Thanks. Triggers was my first thought, but chapter 35 on Triggers didn't
really indicate a way I could do this easily and scared me with a lot of
c code. Maybe it is a good idea to present some of the more common
things you would want to do with triggers in the triggers chapter?

Jeff

---

From: Tom Lane <[email-masked]>
Date: Wed, 12 Oct 2005 22:52:04 -0400

Jeff Williams <[email-masked]> writes:
> c code.

Yeah.  This is a documentation issue that's bothered me for awhile.
The problem is that we treat the PL languages as add-ons and therefore
the documentation of the "core" system shouldn't rely on them ... but
that leaves us presenting C-code triggers as the only examples in
chapter 35.  There is a paragraph in there suggesting you go look at
the PL languages first, but obviously it's not getting the job done.

Anybody have a better idea?

			regards, tom lane

---

From: Michael Glaesemann <[email-masked]>
Date: Thu, 13 Oct 2005 12:07:47 +0900

> the PL languages first, but obviously it's not getting the job done.

I think examples in PL/pgSQL would perhaps be most appropriate, as  
it's a PostgreSQL-specific language, arguably easy to read, and a PL  
that doesn't rely on any external dependencies, so it should be  
relatively easy for people to install it if they want. (IIRC, there's  
even been discussion in the past of whether or not PL/pgSQL should be  
installed by default.)

Michael Glaesemann
grzm myrealbox com

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Oct 2005 10:22:53 -0400

> Anybody have a better idea?

It could just be made a little friendlier, I think.  At the beginning
of the trigger chapter is this:

--snip--
This chapter describes how to write trigger functions. Trigger
functions can be written in C or in some of the available procedural
languages. It is not currently possible to write a SQL-language
trigger function.
--snip--

We could just add a little note by way of modification.  Here's a
(somewhat verbose, I fear) suggestion:

--snip--
This chapter describes how to write trigger functions. Trigger
functions can be written in C or in some of the available procedural
languages. This chapter deals only with functions that are written in
C. If you are unfamiliar with C, you may want also to look at the
chapters on procedural languages, because there are some examples
there that may be easier for you to understand.  To use a procedural
language for a trigger, you will need to install that language; see
the relevant chapter for instructions on how to do so.  It is not
currently possible to write a SQL-language trigger function.
--snip--

A

-- 
Andrew Sullivan  | [email-masked]
The plural of anecdote is not data.
		--Roger Brinner

---

From: "Jim C. Nasby" <[email-masked]>
Date: Thu, 13 Oct 2005 12:20:43 -0500

> the PL languages first, but obviously it's not getting the job done.

Chapter 35 is plpgsql.. do you mean chapter 32.4?

> Anybody have a better idea?

What about a See Also section ala man pages that links to trigger info
for other languages?
-- 
Jim C. Nasby, Sr. Engineering Consultant      [email-masked]
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

---

From: Mike Diehl <[email-masked]>
Date: Thu, 13 Oct 2005 11:45:16 -0600

Is a working example something that people would like to see?  Or is this 
considered a good use of research time?

On Thursday 13 October 2005 11:20 am, Jim C. Nasby wrote:
> > > Thanks. Triggers was my first thought, but chapter 35 on Triggers
> > > didn't really indicate a way I could do this easily and scared me with
> > > a lot of c code.
> >

-- 
Mike Diehl,
Network Monitoring Tool Devl.
SAIC at Sandia National Laboratories.
(505) 284-3137