On Fri, Sep 11, 2026 at 11:14 AM Tom Lane <[email protected]> wrote: > Users > don't always have the luxury of being able to follow the advice to > "use the newest pg_dump to make your dump".
I completely agree with this. But when they don't, things break pretty regularly. Just to take one example, adding a new parser keyword can require quoting to be added to older dumps, which obviously won't work if the list of identifiers needing quoting is taken from the target system's tables rather than pg_dump's own knowledge. I one hundred percent agree that we shouldn't cause that sort of breakage any more often than necessary, but there is ample evidence that we find it necessary on a pretty regular basis. If we put ourselves in a situation where using the correct version of pg_dump is no longer sufficient to deal with these sorts of situations, we are going to have a lot of very sad users. That's one of many reasons why I do not think this feature can share code with pg_dump in any meaningful way. We either decide that we're OK with having this feature for situations where people just want a quick SQL representation of an existing object without worrying about all the stuff pg_dump deals with, or we discard the feature. I don't think there's an intermediate world where this feature can serve the needs of pg_dump. I'd love to be wrong; if somebody has a great idea, cool. But I don't see it. -- Robert Haas
