There was actually something standing on top of my mind? How about
some refactoring of stats_import.sql regarding the queries that check
the diffs in stats? I was wondering if we could limit the bloat by
encapsulating these in one or more PL or SQL functions that provide
records of the diff records found, if any. Not mandatory, still that
could be nice..
I had thought the same, but had dismissed the idea thinking that 1) nobody else would want it and 2) encapsulating the output in functions/views takes the reader that much further away from the core problem. Given that #1 is no longer true, I'll experiment a bit to see what we can do to trim things down. My initial bag of tricks is thus:
1. Creating wiews to filter out oid columns allowing for SELECT * FROM x EXCEPT SELECT * FROM y type comparisons.
2. Functions that do the same as 1.
Both of those suffer from the fact that any new columns added to the tables wouldn't be there and we'd silently miss differences. With that in mind I thought of
3. convert the record to jsonb, deleting the known annoying column keys (oids, timestamps, etc) and then set-differencing those.
4. do the views, but add in a regression check on the number of columns in the base table, with a comment that says "if this check ever fails, the new column(s) have to be added to the view above".
For the reasons stated, I think it's down to options 3 and 4. Any preferences?
