Table rename resistant versioning function & trigger

[mlt]

I suggest to use relation OID instead of a name while calling versioning function from a trigger. This way one can rename history table without a need to recreate a trigger with an updated call to versioning.

Maybe implement versioning2 that takes oid, casts it to regclass and calls standard versioning? Or, actually, other way around replacing heap_openrv with heap_open and alike?

P.S. I do some nasty things with PG and I deal with a bunch of versioned tables that might get renamed.

[arkhipov]

The idea looks OK to me, but I doubt if I can implement it because trigger arguments is an array of text, so you cannot pass either oid or regclass (which, in fact, is an alias for oid) as an argument.

[mlt]

That can work same way I suppose, i.e. by casting text to integer with atol() or something. It is not a big deal for me as a user as I do execute format ... from pgSQL so I can get OID of a table and cast it to a text.

[mlt]

Apparently, we got to invalidate hash entry with a cached plan as somehow it wants to execute inserts with a former table (before rename). I'm surprised plan doesn't use oids... unless I'm missing something.

Indeed, it reinterprets prepared plan. Uhm... could we ditch SPI_prepare and friends in favor of (simple_)heap_insert as suggested by johto on #postgresql IRC?

We can just check names while deciding on hash entry invalidation for now.