Re: Adding SHOW CREATE TABLE

Kirk Wolak <wolakk@gmail.com>

From: Kirk Wolak <wolakk@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Jelte Fennema <postgres@jeltef.nl>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2023-06-02T14:57:06Z
Lists: pgsql-hackers
On Thu, Jun 1, 2023 at 4:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:

> On 2023-06-01 Th 16:39, Kirk Wolak wrote:
>
> 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 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...