Optionally use history table oid in trigger definition

[mlt]

DO NOT MERGE THIS!

[arkhipov]

Wow! You have done a lot since the last time we discussed this issue. I was a bit busy at the time, but I will review the PR this weekend. I was not sure if I could implement the trigger such that it would work properly with backup/restore since OIDs are not persistent over backups, so I put it off. Does your version work properly when restored from a backup?

[mlt]

Hey! Good to hear back! Nope, indeed it doesn't backup/restore table OIDs thus making versioning broken upon restore. Perhaps, we could get by with a big fat warning for those willing to use OIDs and some auxiliary functions digging pg_trigger catalog and checking orphaned items in tgargs. In most cases, I think, users default to \<table name>_history naming pattern so for each table with orphaned trigger (BOTH oid AND name based) we can look around in the same schema as a troubled table for one starting with the same name but different oid to suggest/fix/reinstall trigger.

select tgrelid::regclass, tgname, proname,
  (regexp_split_to_array(tgargs::text, '\\000'))[:tgnargs] args,
  rels, _oids
from pg_trigger t
join pg_proc p on t.tgfoid=p.oid
join lateral (
    select array_agg(relname) rels, array_agg(oid) _oids
    from pg_class c
    where position(tgrelid::regclass::text in relname)=1
      and c.oid!=tgrelid
  ) candidates on true

"versioning";"versioning_trigger";"versioning2";"{sys_period,270603,false}";"{versioning_history}";"{16468}"

P.S. I wonder where they (PG) define _CRT_SECURE_NO_WARNINGS for visual studio to be able to use strncpy.