Re: Adding SHOW CREATE TABLE

Greetings,

* Kirk Wolak (wolakk(at)gmail(dot)com) wrote:
> On Fri, May 12, 2023 at 4:37 PM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * 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.

I didn't say anything was wrong with that, merely pointing out that
having the same set of code for these various use-cases would be better
than having multiple copies of it. The existing code works just fine to
answer the question of "when on v15, what is the v15 query?", it just
happens to *also* answer "when on v15, what is the v14 query?" and we
need that already for postgres_fdw and for pg_dump.

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

I mean ... it's already in postgres_fdw, just not in a way that can be
returned to the user. I don't think I'd want this functionality to
depend on postgres_fdw or generally on an extension though, it should
be part of core in some fashion.

> > 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".

I'd think the FDW code would be the best starting point, but, sure, look
at all the options.

> 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...)

I'd look at the IMPORT FOREIGN SCHEMA stuff in postgres_fdw. We're
already largely answering these questions by what options that takes.
To some extent, the same is true of pg_dump, but at least postgres_fdw
is already backend code and probably a bit simpler than the pg_dump
code. Still, looking at both would be a good idea.

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

Eh, that's an independent discussion and effort, especially because
people are possibly going to want that to generate the necessary ALTER
TABLE commands from the result and not just a DROP/CREATE TABLE.

> 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.

Sure.

> But it's a big commitment. I don't mind if it has a reasonable chance of
> being accepted.

Yes, it's a large effort, no doubt.

> 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.

I don't think we can say one way or the other on this ...

Thanks,

Stephen