Re: Adding SHOW CREATE TABLE - Mailing list pgsql-hackers

From Kirk Wolak
Subject Re: Adding SHOW CREATE TABLE
Date
Msg-id CACLU5mR_ALMeiM_XHmzRNy6dxHg2kJYMQqAw=f-pKZzj3cQ=KQ@mail.gmail.com
Whole thread Raw
In response to Re: Adding SHOW CREATE TABLE  (Andrew Dunstan <andrew@dunslane.net>)
List 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...

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [PATCH] Missing dep on Catalog.pm in meson rules
Next
From: Kirk Wolak
Date:
Subject: Re: [BUG] pg_dump does not properly deal with BEGIN ATOMIC function