Fwd: Start up question about triggers

I did some research and can't even find a way to get meta data in a trigger.

In a trigger, is there a way to inspect OLD and NEW to see what columns are
there and see what has changed? If so, you may not be able to grab the
actual query but you could create a generic trigger that reconstructs a
possible update/insert/delete for any table in your database.

Does anyone know of a good place to go get information about using meta data
in a stored procedure or trigger?

Thanks,
Aaron

On 6/22/06, Forums @ Existanze <forums(at)existanze(dot)com> wrote:

> Thank you for your answer,
>
> We had though about your solution, the problem is that we have around 80
> tables at the moment so your method would suggest adding another 80.
>
> I was wondering if it was possible to retrieve the query in the trigger
> function, cause what we wanted to achieve was to trigger a query log when
> any insert or update or delete operation was made on any of the 80 tables.
> This way we would have something like a query log table. Which will have the
> queries in the order that they were executed by n number of clients.
>
> Say one client updates a row, and the next client deletes it, we want to
> know the queries that occurred in that particular order.
>
> I hope this makes some sense :-)
>
> I should also mention that what we are trying to achieve is some sort of
> partial backup operation. Because of bad initial design, we didn't foresee
> this comming. So now we have two options, changing all the tables,queries
> and code, to contain two timestamps columns representing created and updated
> row, a flag for deleted row, and have some sort of maintanance operation
> that will clean all the deleted records, and create insert/update statements
> for those records that have been updated ie( time_of_update >
> time_of_creation). This will give us a list of operation (INSERT OR UPDATE
> statements) that can be written to a file, and run from a file.
>
> So if I had 10 partiall backups and ran them sequencially I would in
> theory have the data that I originally had. At the moment we are doing full
> back using pgdump, but this is another type of requirement.
>
>
> Any ideas greatly appreciated.
>
> Best Regards,
> Fotis
>