Displaying and dumping of table access methods

Hi,

Over in [1] we're discussing the development of the pluggable storage
patchset, which allows different ways of storing table data.

One thing I'd like to discuss with a wider audience than the
implementation details is psql and pg_dump handling of table access
methods.

Currently the patchset neither dumps nor displays table access
methods . That's clearly not right.

The reason for that however is not that it's hard to dump/display
code-wise, but that to me the correct behaviour is not obvious.

The reason to make table storage pluggable is after all that the table
access method can be changed, and part of developing new table access
methods is being able to run the regression tests.

A patch at [2] adds display of a table's access method to \d+ - but that
means that running the tests with a different default table access
method (e.g. using PGOPTIONS='-c default_table_access_method=...)
there'll be a significant number of test failures, even though the test
results did not meaningfully differ.

Similarly, if pg_dump starts to dump table access methods either
unconditionally, or for all non-heap AMS, the pg_dump tests fail due to
unimportant differences.

A third issue, less important in my opinion, is that specifying the
table access method means that it's harder to dump/restore into a table
with a different AM.

One way to solve this would be for psql/pg_dump to only define the table
access methods for tables that differ from the currently configured
default_table_access_method. That'd mean that only a few tests that
intentionally test AMs would display/dump the access method. On the
other hand that seems like it's a bit too much magic.

While I don't like that option, I haven't really come up with something
better. Having alternative outputs for nearly every test file for
e.g. zheap if/when we merge it, seems unmaintainable. It's less insane
for the pg_dump tests.

An alternative approach based on that would be to hack pg_regress to
magically ignore "Access method: ..." type differences, but that seems
like a bad idea to me.

Greetings,

Andres Freund

[1] https://postgr.es/m/20180703070645.wchpu5muyto5n647%40alap3.anarazel.de
[2] https://postgr.es/m/CA+q6zcWMHSbLkKO7eq95t15m3R1X9FCcm0kT3dGS2gGSRO9kKw@mail.gmail.com
[3] https://postgr.es/m/20181215193700.nov7bphxyge4qkez@alap3.anarazel.de