Re: Adding SHOW CREATE TABLE

From: Kirk Wolak <wolakk(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathaniel Sabanski <sabanski(dot)n(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Adding SHOW CREATE TABLE
Date: 2023-05-12 23:00:23
Message-ID: CACLU5mROQewFBFXG=C6DMvEtDgGZoF9k=m_bkTJYFgSNZptUkg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

On Fri, May 12, 2023 at 4:37 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> Greetings,
>
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> > Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > > Again, would be great to see someone actually work on this. There's
> > > already a good chunk of code in core in pg_dump and in the postgres_fdw
> > > for doing exactly this and it'd be great to consolidate that and at the
> > > same time expose it via SQL.
> ...
> No, it won't make sense to have yet another copy that's for the
> currently-running-server-only, which is why I suggested it go into
> either a common library or maybe into libpq. I don't feel it would
> be bad for the common code to have the multi-version understanding even
> if the currently running backend will only ever have the option to ask
> for the code path that matches its version.
>
> Hmmm... What's wrong with only being for the currently running server?
That's all I would expect. Also, if it was there, it limits the
expectations to DDL that
works for that server version.

Also, if it's on the backend (or an extension), then it's available to
everything.

> Agreed- someone needs to have a fair bit of time and willingness to push
> on this to make it happen.
>

If we can work through a CLEAR discussion of what it is, and is not. I
would be
happy to work on this. I like referencing the FDW. I also thought of
referencing
the CREATE TABLE xyz(LIKE abc INCLUDING ALL). While it's not doing DDL,
it certainly has to be checking options, etc. And pg_dump is the "gold
standard".

My approach would be to get a version working. Then figure out how to
generate "literally" all table options, and work the process. The good news
is that at a certain point the resulting DDL should be "comparable" against
a
ton of test tables.

Where do we draw the lines? Does Table DDL include all indexes?
It should include constraints, clearly. I would not think it should have
triggers.
Literally everything within the <<CREATE TABLE X(...);>>. (ie, no ALTER ..
OWNER TO...)

Next, I would want psql \st to simply call this?

FWIW, we parse our pg_dump output, and store the objects as individual DDL
files.
So, I have about 1,000 tables to play with, for which I already know the
DDL that pg_dump uses.

But it's a big commitment. I don't mind if it has a reasonable chance of
being accepted.
I accept that I will make a few mistakes (and learn) along the way.
If there are ANY deal killers that would prevent a reasonable solution from
being accepted,
please let me know.

Kirk...

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Stephen Frost 2023-05-13 00:36:59 Re: Adding SHOW CREATE TABLE
Previous Message Peter J. Holzer 2023-05-12 20:39:41 Re: Death postgres

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2023-05-12 23:01:49 Re: Large files for relations
Previous Message Michael Paquier 2023-05-12 22:56:56 Re: WAL Insertion Lock Improvements