469,931 Members | 1,831 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,931 developers. It's quick & easy.

simple auto-updating timestamp ?

Hello list,

I suspect, this is a common issue for newbies.
Is there a simple way to have an auto-updating timestamp like mysql has ?

create table something (
id int4,
sometext text,
update_ts timestamp(0),
primary key (id)
);

Everytime this table gets updated the timestamp should be automatically
refreshed to NOW() ?
I hope someone could point me to an example.
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 12 '05 #1
3 9298
Andreas wrote:
I suspect, this is a common issue for newbies.
Is there a simple way to have an auto-updating timestamp like mysql has ?

create table something (
id int4,
sometext text,
update_ts timestamp(0),
primary key (id)
);

Everytime this table gets updated the timestamp should be
automatically refreshed to NOW() ?
I hope someone could point me to an example.


You can do this by adding a trigger to your table. Just define the trigger
to be invoked on INSERT and UPDATE for your table. The trigger definition
would look something like this:

CREATE TRIGGER "trg_set_update_ts" BEFORE INSERT OR UPDATE
ON "public.something" FOR EACH ROW
EXECUTE PROCEDURE "public"."set_update_ts"();

Then, your function in PL/PGSQL that sets the update_ts to NOW() would look
something like this:

CREATE FUNCTION "public"."set_update_ts" () RETURNS trigger AS'
BEGIN
NEW.update_ts = NOW();
RETURN NEW;
END;
'LANGUAGE 'plpgsql' IMMUTABLE CALLED ON NULL INPUT SECURITY INVOKER;

Of course, this function would end up setting the update_ts to NOW() every
time you insert or update your table. And you could never set the value
to anything other than NOW() because your trigger would catch it and set it
back to NOW() again. If that's not exact, it'll at least point you in
the right direction.

Dante

----------
D. Dante Lorenso
da***@lorenso.com



---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 12 '05 #2
D. Dante Lorenso wrote:
You can do this by adding a trigger to your table. Just define the
trigger
to be invoked on INSERT and UPDATE for your table. The trigger
definition
would look something like this: [...]
Thanks.
So far that works for one table.

Can I have this behaviour somehow inherited by child-tables ?
Like:
CREATE TABLE objects (
id integer primary key,
created_ts timestamp(0) DEFAULT LOCALTIMESTAMP,
update_ts timestamp(0),
deleted_ts timestamp(0), -- things get ignored in normal
processing
....
);

Then create a trigger as in your example that updates this timestamp.

Every other table in the db would inherit (objects) to get those
standard fields that I'd like to have everywhere. It'd be nice not
having to bother about the "methods" of the objects-class for every
child-class.
CREATE FUNCTION "public"."set_update_ts" () RETURNS trigger AS'
BEGIN
NEW.update_ts = NOW();
RETURN NEW;
END; 'LANGUAGE 'plpgsql' IMMUTABLE CALLED ON NULL INPUT SECURITY
INVOKER;
I entered your code into psql and checked it afterwards with pgadmin3.
pgadmin shows some parts different to the code that I pushed through psql :
1) create OR REPLACE ...
2) immuntable; <-- End of line What does this part behind
"immutable" do ?
Of course, this function would end up setting the update_ts to NOW()
every
time you insert or update your table. And you could never set the value
to anything other than NOW() because your trigger would catch it and
set it
back to NOW() again.


That is what I had in mind. I'd like to see when there was the last
update to a record.
.... Andreas

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 12 '05 #3
Andreas wrote:
D. Dante Lorenso wrote:
You can do this by adding a trigger to your table. Just define the
trigger
to be invoked on INSERT and UPDATE for your table. The trigger
definition
would look something like this: [...]

Thanks.
So far that works for one table.

Can I have this behaviour somehow inherited by child-tables ?
Like:
CREATE TABLE objects (
id integer primary key,
created_ts timestamp(0) DEFAULT LOCALTIMESTAMP,
update_ts timestamp(0),
deleted_ts timestamp(0), -- things get ignored in normal
processing
...
);

Then create a trigger as in your example that updates this timestamp.
Every other table in the db would inherit (objects) to get those
standard fields that I'd like to have everywhere. It'd be nice not
having to bother about the "methods" of the objects-class for every
child-class.


Yeah I know what you mean. Someone jump in here and correct me if I'm
wrong,
but I don't believe that triggers are inherited in PG. Of course, you
already
have the 'set_update_ts' function defined, so you would only have to declare
the trigger for every child table (not the function).

Verify that this is true. Last time I checked i think that's how it worked.
CREATE FUNCTION "public"."set_update_ts" () RETURNS trigger AS'
BEGIN
NEW.update_ts = NOW();
RETURN NEW;
END; 'LANGUAGE 'plpgsql' IMMUTABLE CALLED ON NULL INPUT SECURITY
INVOKER;

I entered your code into psql and checked it afterwards with pgadmin3.
pgadmin shows some parts different to the code that I pushed through
psql :
1) create OR REPLACE ...
2) immuntable; <-- End of line What does this part behind
"immutable" do ?


You probably want to remove the 'IMMUTABLE CALLED ON NULL INPUT SECURITY
INVOKER'.
That was my cut-and-paste error. I meant to strip that off for you.
Here's the
page that explains what all those do, though:

http://www.postgresql.org/docs/7.4/s...efunction.html

Dante

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

24 posts views Thread by firstcustomer | last post: by
3 posts views Thread by hzgt9b | last post: by
4 posts views Thread by Arun | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.