Re: Extending USING [heap | mytam | yourtam] grammar and behavior

> On Jun 15, 2022, at 8:51 PM, Michael Paquier <michael(at)paquier(dot)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 this second 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 how they interact. But that's superfluous to the issue of just trying to leverage the existing tests as much as I can without having 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 any of 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