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+q6zcwmhsblkko7eq95t15m3r1x9fccm0kt3dgs2ggsro9...@mail.gmail.com [3] https://postgr.es/m/20181215193700.nov7bphxyge4q...@alap3.anarazel.de
