On 6/1/20 3:09 AM, Hans wrote:
I've had a weird problem in a production system. The customer had
installed a new server with our software on it. The software installs
a Postgres database schema that includes a number of triggers. The
triggers perform inserts into an additional table.
How is the install done?
Our instructions tell them to apt-get it from the default repository. I
can ask on tuesday for more information.
But there is more to it then that as you show below. So what is the
outline for a customer to get from clean server to one with your
software fully installed?
The Postgres logs from the period the below was run might be
informative. I'm guessing that is going to have to wait until Tuesday.
Our software contains no code for disabling triggers. It creates them
once, during database initialisation (i.e. before any data is put
in), and then leaves them alone. I have no reason to believe the
customer messed with the database either.
Exactly how is that done?
We give them a C++ program that creates the tables, and then executes:
CREATE OR REPLACE FUNCTION generic.update_usergrouptest_from_test()
RETURNS trigger AS $$
DECLARE
x INTEGER;
BEGIN
IF NEW.usergroup_ids <> OLD.usergroup_ids THEN
DELETE FROM generic.usergroup_test WHERE test_id = NEW.id;
FOREACH x IN ARRAY NEW.usergroup_ids LOOP
INSERT INTO generic.usergroup_test (test_id, usergroup_id) VALUES
(NEW.id, x);
END LOOP;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
and then
CREATE TRIGGER update_usergrouptest_from_test
AFTER UPDATE ON generic.test
FOR EACH ROW EXECUTE PROCEDURE generic.update_usergrouptest_from_test();
Hans
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
