On 16 Jan 2023, at 8:59, p...@pfortin.com wrote: > encodings for database "template1" do not match: old "UTF8", new > "SQL_ASCII" Failure, exiting > Suggest the old dB using UTF8 is the better practice, and the new dB should do likewise
> "template1" is not a DB I've ever messed with; so this will require that > I fire up the old version and change the encoding somehow? > This is created at initdb and mostly you don’t need/want to mess with it > Is this likely to repeat for my actual databases? > AFAICT the least work option is to redo the initdb for the new v15.1 database. There is a lot of pain (and potential data corruption) to be had trying to reconfigure the old one before it can be moved. Personally, UTF8 is the way to go. It will handle everything in the old database and the future brings to the new one. I can see no advantage in pure ASCII when there is the potential for the real world to be contributing text. And there could well be non-ASCII characters lurking in the old dB, especially since someone set it up to receive them. Regards Gavan Schneider —— Gavan Schneider, Sodwalls, NSW, Australia Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong. — H. L. Mencken, 1920
