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

On Wed, Jun 15, 2022 at 06:16:21PM -0700, Mark Dilger wrote:
> When developing two or more TAMs, this falls apart. Some tests may
> be worth fixing up (perhaps with alternate output files) for
> "mytam", but not for "columnar_tam". That might be because the test
> is checking fundamentally row-store-ish properties of the table,
> which has no applicability to your column-store-ish TAM. In that
> case, "USING NOT columnar_tam" fixes the test failure when columnar
> is the default, without preventing the test from testing "mytam"
> when it happens to be the default.

I think that it is very important for the in-core test suite to remain
transparent in terms of options used for table AMs (or compression),
and this has improved a lot over the last years with options like
HIDE_TABLEAM and HIDE_TOAST_COMPRESSION. Things could have actually
more ORDER BY clauses to ensure more ordering of the results, as long
as the tests don't want to stress a specific planning path. 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. Am I getting that right? Why is a grammar
extension necessary for what looks like a test structure problem when
there are interdependencies across multiple AMs developped?

> Once you have enough TAMs developed and deployed, this USING NOT
> business becomes useful in production. You might have different
> defaults on different servers, or for different customers, etc., and
> for a given piece of DDL that you want to release you only want to
> say which TAMs not to use, not to nail down which TAM must be used.

I am not sure to see why this would be something users would actually
use in prod. That means to pick up something else than what the
server thinks is the best default AM but where somebody does not want
to trust the default, while generating an error if specifying the
default AM in the USING NOT clause. On top of that
default_table_access_method is user-settable.
--
Michael