> On Jun 15, 2022, at 8:51 PM, Michael Paquier <michael@paquier.xyz> wrote:
>
> However,
> your problem is basically that you develop multiple AMs, but you want
> to have regression tests that do checks across more than one table AM
> at the same time.
It is true that I test multiple table AMs at the same time, but that's a somewhat different concern.
> Am I getting that right?
Not exactly.
> Why is a grammar
> extension necessary for what looks like a test structure problem when
> there are interdependencies across multiple AMs developped?
Ok, I didn't want to get into my exact process, because it involves other changes that I don't expect -hackers to want.
But basically what I do is:
./configure --with-default-tam=chicago && make && make check-world
That fails for a few tests, and I manually change the create table statements in tests that are not chicago-compatible
to"using not chicago". Then
./configure --with-default-tam=detroit && make && make check-world
That fails for some other set of tests, but note that the tests with "using not chicago" are still using detroit in
thissecond run. That wouldn't be true if I'd fixed up the tests in the first run "using heap".
Then I can also add my own tests which might make some chicago backed tables plus some detroit backed tables and see
howthey interact. But that's superfluous to the issue of just trying to leverage the existing tests as much as I can
withouthaving to reinvent tests to cover "chicago", and then reinvent again to cover "detroit", and so forth.
If you develop enough TAMs in parallel, and go with the "using heap" solution, you eventually have zero coverage for
anyof the TAMs, because you'll eventually be "using heap" in all the tables of all the tests.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company