Re: Adding SHOW CREATE TABLE

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 20:36:51
Message-ID: ZF6jY1vqhxfGME+b@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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.
>
> Note that this is hardly new ground: we've heard more-or-less the same
> proposal many times before. I think the reason it's gone nowhere is
> that most of the existing infrastructure is either in pg_dump or designed
> to support pg_dump, and pg_dump is *extremely* opinionated about what
> it wants and how it wants the data sliced up, for very good reasons.
> Reconciling those requirements with a typical user's "just give me a
> reconstructed CREATE TABLE command" request seems fairly difficult.

Yet we're already duplicating much of this in postgres_fdw. If we don't
want to get involved in pg_dump's feelings on the subject, we could look
to postgres_fdw's independent implementation which might be more
in-line with what users are expecting. Having two separate copies of
code that does this and continuing to refuse to give users a way to ask
for it themselves seems at the least like an odd choice.

> Also, since pg_dump will still need to support old servers, it's hard
> to believe we'd accept any proposal to move that functionality into
> the server side, which in turn means that it's not going to be an easy
> SQL command.

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.

> These issues probably could be surmounted with enough hard work, but
> please understand that just coming along with a request is not going
> to cause it to happen. People have already done that. (Searching
> the mailing list archives might be edifying.)

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

Thanks,

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2023-05-12 20:39:41 Re: Death postgres
Previous Message Tom Lane 2023-05-12 20:27:51 Re: Adding SHOW CREATE TABLE

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-05-12 20:37:21 improve more permissions-related error messages
Previous Message Tom Lane 2023-05-12 20:27:51 Re: Adding SHOW CREATE TABLE