Re: Displaying and dumping of table access methods - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Displaying and dumping of table access methods
Date
Msg-id 20190108173446.2o55czddnpaa67mz@alap3.anarazel.de
Whole thread Raw
In response to Re: Displaying and dumping of table access methods  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Displaying and dumping of table access methods  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
Hi,

On 2019-01-08 11:30:56 +0100, Peter Eisentraut wrote:
> On 08/01/2019 00:56, Andres Freund wrote:
> > 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.
> 
> For psql, a variable that hides the access method if it's the default.

Yea, I think that seems the least contentious solution.  Don't like it
too much, but it seems better than the alternative. I wonder if we want
one for multiple regression related issues, or whether one specifically
about table AMs is more appropriate. I lean towards the latter.


> > 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.
> 
> For pg_dump, track and set the default_table_access_method setting
> throughout the dump (similar to how default_with_oids was handled, I
> believe).

Yea, that's similar to that, and I think that makes sense.

Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Displaying and dumping of table access methods
Next
From: Alexander Korotkov
Date:
Subject: Re: GSoC 2019