Andres Freund <[email protected]> writes:
> On 2026-09-11 00:55:54 -0400, Tom Lane wrote:
>> I'm a bit confused why you say that. To my mind, if we were going
>> to proceed in this direction, version skew would ideally be solved
>> like this:
>>
>> 1. Server-side DDL-reconstruction functions only need to work with
>> their particular server version; necessarily so, since that's the
>> only catalog data they'll ever see.
>>
>> 2. pg_dump just calls the source server's DDL-reconstruction functions
>> and doesn't have to worry about version skew.
> Isn't the problem with that that we occasionally need to adapt the syntax
> between versions to some degree? I think it has become less common, but I'm a
> bit sceptical that it's wise to decide we won't ever again need that...
I think we try very very hard to avoid making changes that would break
existing dump files. There are certainly times where we change what
pg_dump prefers to output, but the server should continue to accept
what pg_dump used to output (at least for quite a few years). 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 wonder if the right thing here would be to separate the "metadata
> collection" aspect from the "SQL generation" aspect. I.e. have a small library
> that can generate DDL statements from its inputs, without any catalog
> accesses. We'd still end up - annoyingly - with two versions of the metadata
> collection (one from syscaches for the get_ddl* SQL functions, one via queries
> for pg_dump), but at least the SQL generation aspect would be deduplicated.
Hmm...
regards, tom lane
