On 2021-Mar-19, Robert Haas wrote: > > Regarding your point, that does look like clutter. We don't annotate > > the dump with a storage clause unless it's non-default, so probably we > > should do the same thing here. I think I gave Dilip bad advice here... > > Here's a patch for that. It's a little strange because you're going to > skip dumping the toast compression based on the default value on the > source system, but that might not be the default on the system where > the dump is being restored, so you could fail to recreate the state > you had. That is avoidable if you understand how things work, but some > people might not. I don't have a better idea, though, so let me know > what you think of this.
Do you mean the column storage strategy, attstorage? I don't think that's really related, because the difference there is not a GUC setting but a compiled-in default for the type. In the case of compression, I'm not sure it makes sense to do it like that, but I can see the clutter argument: if we dump compression for all columns, it's going to be super noisy. (At least, for binary upgrade surely you must make sure to apply the correct setting regardless of defaults on either system). Maybe it makes sense to dump the compression clause if it is different from pglz, regardless of the default on the source server. Then, if the target server has chosen lz4 as default, *all* columns are going to end up as lz4, and if it hasn't, then only the ones that were lz4 in the source server are going to. That seems reasonable behavior. Also, if some columns are lz4 in source, and target does not have lz4, then everything is going to work out to not-lz4 with just a bunch of errors in the output. -- Álvaro Herrera 39°49'30"S 73°17'W
