Thread

Re: Adding SHOW CREATE TABLE

Kirk Wolak <wolakk@gmail.com> — 2023-06-01T20:39:14Z

On Thu, Jun 1, 2023 at 3:13 PM Andrew Dunstan <andrew@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 code I did see was checking what server
options were available. (I clearly could have missed something)...  But
exactly how would that work?  All it knows is who it is (pg_dump V14, for
example.  So the best case is that it ignores new things that would be in
V15, V16 because it doesn't even know what to check for or what to do).
Which, to me, makes it more of a side-effect than a feature, no?

And that if it used a server side solution, it gets an interesting "super
power".  In that even pg_dump V20 could dump a V21 db with V21 syntax
enhancements.  (I cannot say if that is desirable or not as I lack 20yrs of
history here).  Finally, the thoughts of implementing this change at this
point, when it would impact anyone using the NEW version to dump an OLD
version without the server side support...  So that migration may never
happen.  Or only after the only supported DBs have the required server side
functions...

The feedback is welcome...