On Fri, 2021-04-30 at 13:33 -0500, Justin Pryzby wrote: > On Sat, Mar 06, 2021 at 03:01:43PM -0500, Tom Lane wrote: > > v4-0001 mostly teaches test.sh about specific changes that have to be > > made to historic versions of the regression database to allow them > > to be reloaded into current servers. As already discussed, this is > > really duplicative of knowledge that's been embedded into the buildfarm > > client over time. It'd be better if we could refactor that so that > > the buildfarm shares a common database of these actions with test.sh. > > And said database ought to be in our git tree, so committers could > > fix problems without having to get Andrew involved every time. > > I think this could be represented as a psql script, at least in > > versions that have psql \if (but that came in in v10, so maybe > > we're there already). > > I started this. I don't know if it's compatible with the buildfarm client, > but > I think any issues maybe can be avoided by using "IF EXISTS".
I'm going to try pulling this into a psql script today and see how far I get. > > But I'm not sure I believe > > that query. It's got hard-wired assumptions about which typtype values > > need to be covered. Why is it okay to exclude range and multirange? > > Are we sure that all composites are okay to exclude? Likewise, the > > restriction to pg_catalog and information_schema schemas seems likely to > > bite us someday. There are some very random exclusions based on name > > patterns, which seem unsafe (let's list the specific type OIDs), and > > again the nearby comments don't match the code. But the biggest issue > > is that this can only cover core datatypes, not any contrib stuff. > > I changed to use regtype/OIDs, included range/multirange and stopped including > only pg_catalog/information_schema. But didn't yet handle composites. Per cfbot, this test needs to be taught about the new pg_brin_bloom_summary and pg_brin_minmax_multi_summary types. --Jacob
