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@aklaver.com