On Wed, Mar 24, 2021 at 12:45 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I wouldn't be proposing this if the xversion failures were the only > reason; making them go away is just a nice side-effect. The core > point is that the charter of pg_dump is to reproduce the source > database's state, and as things stand we're failing to ensure we > do that.
Well, that state is just a mental construct, right? In reality, there is no such state stored anywhere in the old database. You're choosing to attribute to it an implicit state that matches what would need to be configured in the newer version to get the same behavior, which is a reasonable thing to do, but it is an interpretive choice rather than a bare fact. I don't care very much if you want to change this, but to me it seems slightly worse than the status quo. It's hard to imagine that someone is going to create a new cluster, set the default to lz4, run pg_upgrade, and then complain that the new columns ended up with lz4 as the default. It seems much more likely that they're going to complain if the new columns *don't* end up with lz4 as the default. And I also can't see any other scenario where imagining that the TOAST compression property of the old database simply does not exist, rather than being pglz implicitly, is worse. But I could be wrong, and even if I'm right it's not a hill upon which I wish to die. -- Robert Haas EDB: http://www.enterprisedb.com
