Hi,

My boss wants to add a special type of logging to some of our tables on
update/delete/insert. I need to log who, when, table_name, field name,
original value and new value for each record, but only logging modified
fields, and he wants me to do this using postgres pgSQL triggers. The
changes would be inserted into a second table.

We are given 10 automatically created variables. Some of which I know I can
use: NEW, OLD, TG_WHEN, TG_OP and TG_RELNAME. I can use these to get
general information for the update, but when the trigger is called, I don't
know how many fields are in the tables that are being updated.

My questions are: Is there a way I can dynamically determine the number of
fields in the rows that is being maintained. (a function much like:
PQnfields(const PGresult *); )
Then I need a way to get the name of the field (using a function much like:
PQfname(const PGresult *, int); )

Using the dynamically generated name I could then walk the NEW and OLD
columns to compare the values. (e.g. if (NEW.field != OLD.field) do
something;

Can anyone help me with this? Thank you in advance.

Tim Vadnais



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

"Tim Vadnais" <tvadnais (AT) earthlink (DOT) net> writes:
I'm starting to think there should be a FAQ entry for this ;-)

plpgsql is essentially incapable of doing anything that involves dynamic
field access, especially if the field types aren't known in advance either.
I believe you can do what you want in pltcl, and you can definitely
write such a trigger in C, but plpgsql is the wrong tool for the job.

If you want to try it in C, there are some relevant examples in
contrib/spi/ in the PG source distribution.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

On Thu, Oct 28, 2004 at 09:14:17AM -0700, Tim Vadnais wrote:
You asked this last week and there were a couple of responses:

http://archives.postgresql.org/pgsql...0/msg01077.php
http://archives.postgresql.org/pgsql...0/msg01097.php
http://archives.postgresql.org/pgsql...0/msg01112.php

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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match