CREATE TRIGGER trigger_now_on_updated
BEFORE UPDATE ON packages
FOR EACH ROW
EXECUTE PROCEDURE now_on_updated_package();
Some preliminary research suggests the following code will allow us to specify via inclusion what columns we want to actually update with, which honestly may make the most sense to utilize since there's only a few that should be actively tracked as end user or package maintainer changes:
CREATE TRIGGER trigger_now_on_updated
BEFORE UPDATE
OF name, data
ON packages
FOR EACH ROW
EXECUTE PROCEDURE now_on_updated_package();
Ideally this should be able to have the table update properly, then after the fact the updated timestamp from the latest version can be taken to replace the value in all previous packages, to undo the damage done from this logic being affected by download count previously
Using the existing update trigger of:
Some preliminary research suggests the following code will allow us to specify via inclusion what columns we want to actually update with, which honestly may make the most sense to utilize since there's only a few that should be actively tracked as end user or package maintainer changes:
Ideally this should be able to have the table update properly, then after the fact the
updated
timestamp from the latest version can be taken to replace the value in all previous packages, to undo the damage done from this logic being affected bydownload
count previously