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