Re: Can we remove support for standard_conforming_strings = off yet?
| От | Andrew Dunstan |
|---|---|
| Тема | Re: Can we remove support for standard_conforming_strings = off yet? |
| Дата | |
| Msg-id | 05d2b753-8764-43eb-b36d-59f108effc74@dunslane.net обсуждение исходный текст |
| Ответ на | Re: Can we remove support for standard_conforming_strings = off yet? (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On 2025-12-31 We 12:04 PM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:On 2025-12-30 Tu 5:50 PM, Tom Lane wrote:As I was working through it, I realized that there's one potentially-nasty point that might cause upgrading problems. To wit, pg_dump and pg_dumpall have historically replicated the source server's standard_conforming_strings setting into their output: they emit a SET command for that, and any string literals appearing in views or the like will be escaped accordingly. So if your old installation had standard_conforming_strings = off, and all you have from it is existing pg_dump output (either text or archive format), you are in a sticky situation because that dump will not restore cleanly.Have we ever promised that dumps made using pg_dump/pg_dumpall from other than the target version work?We may not promise it, but I think we've always tried very hard to not break old pg_dump files, precisely because they might be the only available backup.I don't see this as a big issue, unless I'm misunderstanding.Personally I would call it a deal-breaker if I thought it'd affect more than a very very tiny number of people. But the entire premise of this patch is that nobody is using standard_conforming_strings = off in production anymore. If that isn't true it's probably a mistake to go forward anyway.
I think you're probably right that very few people are using it. Not sure how we'd find out if they are, though.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: