Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1196
  • Last Modified:

Using the OLD record in a trigger to pull back dynamic column names

I am trying to create a trigger in postgresql using the OLD record

basically the column I want to refer to will be in a string for example:

myColumn = "some_column_name";

however doing it like this would mean that it would be looking for a column called myColumn

Does anyone know if it is possible to pull back an OLD record with a dynamic record as the column name?
1 Solution
earth man2Commented:
an old record cannot be "dynamic??"
what do you mean by dynamic ??
old.x at the end of the day refers to a table record.
triclAuthor Commented:
for example if there is a table with column names:

col1, col2, col3, col4

I could then refer to the fields with some kind of loop

for (i=0;i<4;i++) {

OLD.col || i


if that makes any more sense to refer to the OLD record dynamically (I know that the loop is not a valid one for plpgsql but it just an example of a loop to show an example of the problem
Let's step back and figure out what you are actually trying to accomplish with your trigger(s) rather than looking at a detailed technique you may not need.  There may be any number of ways to accomplish the overall goal.

What, in general, do the triggers do?  How many do you have to create?

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

triclAuthor Commented:
the idea is to log every update made to any single field

so there will be a table called table_log with the fields:

id, ref_id, table_name, fieldname, oldfieldvalue, newfieldvalue

so I will create a function which will essentially be the same code for each table that is used on an update trigger to store the fieldname, table name the row id and the new and old value for that field

essentially that is what I want to be able to do, this way I am then able to store and refer back to any historical record.

I will plan to do the same kind of method for delete operation too so nothing will be deleted or changed without having a audit log of it

Hope this makes more sense for what I am needing it for. I have the function ready so all of the logic / code is there just need to refer to a dynamic OLD record
O.K.  Take a look at the entire discussion on the following EE Question.  This person had a similar requirement in Sybase ASA.

The point made in Q_22860493 is that it is not such a good idea to try and log every field change anyway.  I presented a workable solution to keeping history/audit information that will work in PostgreSQL as well.

Check it out and let us know what you think.

triclAuthor Commented:
I have read through that question/answers however I dont think it totally relates to my issue. The reason for wanting to be able to refer to the OLD and NEW records dynamically is that I can then use the same function for all tables. Rather than having to declare each column for each table to be inserted.

Also by it being just one function, if I then want to advance or change it I only have to change it in one place (modifications to the function)

For example in PHP this would be done with
$stringName = "mystring";
$stringValue = "mystringvalue";

I understand what you are saying with regards to performance of storing every field that is changed on a table, however for this particular project / database use the majority of queries will be SELECT or INSERT UPDATES will not happen as a main task, but need to be logged to protect ourselves

Is there any similar way to achieve what I need as there is in PHP ? the language I am using for PostgreSQL is plpgsql but can use another language if required as well if it offers the solution to what I need

I have given more points to this issue as it appears to be more complex than I originally thought it would be

Why not write a little code generator that creates the Update/Delete triggers automatically based on the meta-data for each target table?  That way you are not stuck writing a custom trigger for each procedure yet you still get reasonable performance and query capabilities of storing an entire record per delta.

triclAuthor Commented:
I didnt really want to do that because then changing any element means changing every function so one for each table

I have come up with a possible solution (code attached) this actually works, yes it is a bit of a "bodge" to a solution but it does store the information I need (although it actually stores more as it will store all of the table column names and values not just the ones that have been adjusted)

The issue is that it actually doesnt update the table I am editing for example

if I edit a table called table1 (id, name)

it will not actually update the value I changed in table1 but it will log the changes I made in the below function into _sys_record_log

failing any other solution I will have to go with the one I have mentioned, however does anyone know any reason why it will not let me update the actual table itself (for example table1) ?
colrec RECORD;
colrecsub RECORD;
colname VARCHAR;
colnamet VARCHAR;
FOR colrec IN
select attname from pg_attribute where attrelid = (select oid from pg_class where relname = TG_RELNAME) and attnum > 0
FOR colrecsub IN
EXECUTE 'SELECT text(' || colrec.attname || ') as coltest FROM ' || TG_RELNAME || ' WHERE id=' || || ';'
coll = colrecsub.coltest;
if coll is not null THEN
INSERT INTO _sys_record_log (ref_table,ref_id,event,field_name,field_value) VALUES (TG_RELNAME,,TG_OP,colrec.attname,coll);
return null;

Open in new window

You can easily do this if you write your function in plpythonu instead of plpgsql.  The "old" and "new" records in the trigger become normal Hash objects, so you can access their keys, and can then dynamically reference columns.

I used this approach successfully to do almost exactly what you describe.
triclAuthor Commented:
I have now come up with a work around, it is not ideal but it will store all of the columns for an updated row,  I can see your solution worth implementing in the future when my work around has started to fill the table up with too many row that are not needed which in turns slows down any future requirements of it. I have not used plpythonu before but will look into how to do it, I am sure it will be easy enough to pick up
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now