On Thu, Jun 1, 2023 at 4:46 PM Andrew Dunstan <and...@dunslane.net> wrote:
> On 2023-06-01 Th 16:39, Kirk Wolak wrote: > > On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan <and...@dunslane.net> wrote: > >> On 2023-06-01 Th 12:57, Kirk Wolak wrote: >> >> PS: It dawned on me that if pg_dump had used server side code to generate >> its DDL, its complexity would drop. >> >> Maybe, that remains to be seen. pg_dump needs to produce SQL that is >> suitable for the target database, not the source database. >> > > First, pg_dump has some special needs in addressing how it creates tables, > to be able to load the data BEFORE indexing, and constraining (lest you > have to struggle with dependencies of FKs, etc etc)... > > But version checking is interesting... Because I found no way to tell > pg_dump what DB to target. > > The target version is implicitly the version it's built from. > Andrew, Thank you. Someone else confirmed for me that the code is designed to create accurate DDL for the pg_dump version. So, for example, WITH OIDs are not included with later versions of pg_dump, even though they are hitting a server with them. Great to know. I like that CITUS offered up something. I think that might be the current best approach. It's a win-win. They get something, we get something. Kirk...
