I've been parsing through the file for our own system, and discovered the Name: <value> for the trigger is not quite the name of the trigger. I've included an example of FUNCTIon for reference.
A function is a standalone object where a trigger cannot exist without being attached to a trigger. Extrapolating the behavior of the later from the former is not all that productive. It definitely doesn't constitute evidence of a bug.
It's "change_log"<space>"id_change_log"; but the actual trigger name is "id_change_log" on the table "change_log"
Parent -> Child is a very common way to write this kind of thing so the order seems perfectly fine.
I would have EXPECTED $ as the function has, but that's part of it's "name" in the function case.
I would think introducing a symbol that physically joins the two components together would be more confusing, not less. One might come to assume it really is the full actual name of the trigger when it is not.
Basically, it's not the correct name. It should simply be "id_change_log" (IMO, to be consistent with every other comment I've seen)
You'll have to show the table name somewhere. If you change this to be just the object name (which has merit) what do you do with that? No matter what you do triggers are unique and so will have some unique aspect to them. Lacking some other similar parent->child but independent object (i.e., not columns) object to compare against, and the fact this is both structured (I am curious what it does for names that require double-quotes, can that space be relied upon to be unambiguous?) and mostly meant for human consumption, I'd be inclined to leave well enough alone.
