On Sun, Jan 17, 2021 at 02:20:10PM -0800, Noah Misch wrote: > On Sun, Jan 17, 2021 at 01:51:35PM +0100, Magnus Hagander wrote: >> Option 3 would be the closest to how other things work though, >> wuodln't it? Normally, it's the job of pg_dump (or pg_dumpall) to >> adapt the dump to the new version of PostgreSQL. > > I didn't do a precedent search, but I can't think of an instance of those > programs doing (3). We have things like guessConstraintInheritance() that > make up for lack of information in old versions, but dumpFunc() doesn't mutate > any proconfig setting values. Is there a particular pg_dump behavior you had > in mind?
I don't recall any code paths in pg_dump touching array parsing that enforces a value to something else if something is not supported. >> In a lot of ways, think (3) seems like the reasonable ting to do. >> That's basically what we do when things change in the table creation >> commands etc, so it seems like the logical place. > > This would be interpreting setconfig='{password_encryption=on}' as "opt out of > future password security increases". I expect that will tend not to match the > intent of the person entering the setting. That said, if v14 were already > behaving this way, I wouldn't dislike it enough to complain. Hm. Up to 13, "on" is a synonym of "md5", so it seems to me that we should map "on" to "md5" rather than "scram-sha-256" on the side of compatibility. But you have a point when it comes to good security practices. It makes me wonder whether it would be better to have pg_dumpall complain rather than pg_upgrade if this value is found in the proconfig items.. pg_upgrade is not the only upgrade path supported. -- Michael
signature.asc
Description: PGP signature