teoljungberg
Is option `on` for #create_trigger useless?
I looked at #create_trigger method code and noticed than option on not used in code. I tried run my migration without this option and migration successful done.
Is option on for #create_trigger useless? What do you think about using this option to interpolate sql definition?
For example:
CREATE TRIGGER update_state_changed_at
BEFORE UPDATE ON %{on}
FOR EACH ROW
WHEN (OLD.state <> NEW.state)
EXECUTE PROCEDURE update_state_changed_at();
I think this is easy and I can make pull request if you don't mind
If it's not used - it's something we should remove. It's probably a relic of an older spike on the implementation.
But what about add feature with variables in triggers?
One trigger file can be reused multiple times for different tables. I think it can be useful and flexible.
Sure - we can do that. But that seems to make more sense as a feature addition rather than making an unused feature into one.
What PR? #57?
I thought you were going to remove the on option, as that is what this issue is about.
Excuse me, I read issue description again and now I see that it is really confusing. As I said - my English is not good :(
I wanted use on option to parametrize trigger, and wrote about it in issue:
What do you think about using this option to interpolate sql definition?
But you said that bad idea to use legacy option for it (and I agreed), and I made PR #57 with new options for interpolate sql definition. I think that idea to remove on option can be so problem, because gem users can run into problem with backward compatibility.
I thought that 'on' could be useful for organizational purposes, e.g. db/triggers/${table_name}/${trigger_name}.sql but otherwise, perhaps we should make a PR to remove it since it's not used?
