Hackers,
I have extended the grammar to allow "USING NOT method [, ...]" to exclude one or more TAMs in a CREATE TABLE
statement. This may sound like a weird thing to do, but it is surprisingly useful when developing new Table Access
Methods,particularly when you are developing two or more, not just one. To explain:
Developing a new TAM takes an awful lot of testing, and much of it is duplicative of the existing core regression test
suite. Leveraging the existing tests saves an awful lot of test development.
When developing just one TAM, leveraging the existing tests isn't too hard. Without much work*, you can set
default_table_access_method=mytamfor the duration of the check-world. You'll get a few test failures this way. Some
willbe in tests that probe the catalogs to verify that /heap/ is stored there, and instead /mytam/ is found. Others
willbe tests that are sensitive to the number of rows that fit per page, etc. But a surprising number of tests just
pass,at least after you get the TAM itself debugged.
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
propertiesof 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
ithappens to be the default.
Once you have enough TAMs developed and deployed, this USING NOT business becomes useful in production. You might have
differentdefaults on different servers, or for different customers, etc., and for a given piece of DDL that you want to
releaseyou only want to say which TAMs not to use, not to nail down which TAM must be used.
Thoughts? I'll hold off posting a patch until the general idea is debated.
[*] It takes some extra work to get the TAP tests to play along.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company