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
