On 2021-Mar-19, Robert Haas wrote: > On Fri, Mar 19, 2021 at 6:22 PM Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote:
> > (At least, for binary upgrade surely you must make sure to apply the > > correct setting regardless of defaults on either system). > > It's not critical from a system integrity point of view; the catalog > state just dictates what happens to new data. Oh, okay. > You could argue that if, in a future release, we change the default to > lz4, it's good for pg_upgrade to migrate users to a set of column > definitions that will use that for new data. Agreed, that seems a worthy goal. > > Maybe it makes sense to dump the compression clause if it is different > > from pglz, regardless of the default on the source server. > > Well, I really do hope that some day in the bright future, pglz will > no longer be the thing we're shipping as the postgresql.conf default. > So we'd just be postponing the noise until then. I think we need a > better idea than that. Hmm, why? In that future, we can just change the pg_dump behavior to no longer dump the compression clause if it's lz4 or whatever better algorithm we choose. So I think I'm clarifying my proposal to be "dump the compression clause if it's different from the compiled-in default" rather than "different from the GUC default". -- Álvaro Herrera Valdivia, Chile "Para tener más hay que desear menos"
