> On 3 Dec 2022, at 20:55, Karsten Hilbert <Karsten.Hilbert@gmx.net> wrote:
>
>> You would need to wrap the function creation calls into some automation to generate and store those diffs, comparing
itback, etc, but that may be doable. I would also generate new diffs right after major version updates of the database
(abefore and after of the output of pg_get_functiondef, applied to the stored diff?).
>
> I wonder whether that would tie the sanity check to a particular PG version.
>
> I mean, pg_get_functiondef output being a server runtime artifact it might
> well change between server versions, no ?
I meant to write: “I would also generate new diffs right _before and_ after…”, precisely for that reason. The before
patchshould get you the last ’sane’ situation to get back to the source code. Next, you can diff that to the newly
tokenisedversion after the upgrade.
It is a bit of a hassle, as you need to remember to do that before an upgrade, but at least you’d have something…
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.
