> If I have time at the weekend, I might have a bash at producing a patch > that will implement what is required. No promises, mind. > > What would be preferred? Convert the trigger to an update trigger, or fire > a delete trigger followed by an insert trigger? > > I'd prefer the former (update) as requested in the ticket. I think it may > be easier to code, as well, but not sure.
Yes, I agree, firing the UPDATE trigger would be better. But I would also be satisfied with an additional DELETE trigger call. BTW, if you release this patch, which SQLite version will it be available for? Only 3.x or also 2.x? > What is stopping you checking for an existing row in the trigger body > yourself? Something like (based on your example): > create trigger table_replace_check > before insert on 'table' > for each row > begin > insert into table_log > select 'D', id, SecDbKey from 'table' > where id=NEW.id; > end; > > Then you just keep a regular post insert trigger to put the new updated > values into the log. The example I posted is a simple case I use for testing. Other people will create different tables with differend fields, and I have no idea how these tables will look like. So, how can I code a trigger for an arbitrary table without doing havy parsing of the incoming "CREATE TABLE" query? No, firing the UPDATE trigger is definitely a better solution :) Regards, Alex
