SHOW CREATE
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t40893psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 23, 2026 at 01:25 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t40893_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t40893_1 && git checkout t40893_1Patchset v1 (message #1) is on t40893_1
Folks,
Corey Huinker put together the documentation for this proposed
feature. Does this seem like a reasonable way to do it?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Fri, Jul 5, 2019 at 12:32 PM David Fetter <david@fetter.org> wrote:
Folks,
Corey Huinker put together the documentation for this proposed
feature. Does this seem like a reasonable way to do it?
In doing that work, it became clear that the command was serving two
masters:
1. A desire to see the underlying nuts and bolts of a given database object.
2. A desire to essentially make the schema portion of pg_dump a server side
command.
To that end, I see splitting this into two commands, SHOW CREATE and SHOW
DUMP.
SHOW DUMP would the original command minus the object type and object name
specifier, and it would dump the entire current database as seen from the
current user (again, no data).
SHOW CREATE would still have all the object_type parameters as before, but
would only dump the one specified object, plus any dependent objects
specified in the WITH options (comments, grants, indexes, constraints,
partitions, all).
Please note that any talk of a server side DESCRIBE is separate from this.
That would be a series of commands that would have result sets tailored to
the object type, and each one would be an inherent compromise between
completeness and readability.
I'd like to hear what others have to say, and incorporate that feedback
into a follow up proposal.
On 2019–07–05, at 12:14, Corey Huinker <corey.huinker@gmail.com> wrote:
In doing that work, it became clear that the command was serving two masters:
1. A desire to see the underlying nuts and bolts of a given database object.
2. A desire to essentially make the schema portion of pg_dump a server side command.To that end, I see splitting this into two commands, SHOW CREATE and SHOW DUMP.
I like the idea of having these features available via SQL as opposed to separate tools. Is it necessary to have specific commands for them? It seems they would potentially more useful as functions, where they'd be available for all of the programmatic features of the rest of SQL.
Michael Glaesemann
grzm seespotcode net
On Sat, Jul 13, 2019 at 06:32:41PM -0500, Michael Glaesemann wrote:
On 2019–07–05, at 12:14, Corey Huinker <corey.huinker@gmail.com> wrote:
In doing that work, it became clear that the command was serving two masters:
1. A desire to see the underlying nuts and bolts of a given database object.
2. A desire to essentially make the schema portion of pg_dump a server side command.To that end, I see splitting this into two commands, SHOW CREATE
and SHOW DUMP.I like the idea of having these features available via SQL as
opposed to separate tools. Is it necessary to have specific commands
for them? It seems they would potentially more useful as functions,
where they'd be available for all of the programmatic features of
the rest of SQL.
Having commands for them would help meet people's expectations coming
from other RDBMSs.
On the other hand, making functions could just be done in SQL, which
might hurry the process along.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
On Fri, Jul 5, 2019 at 1:14 PM Corey Huinker <corey.huinker@gmail.com> wrote:
I'd like to hear what others have to say, and incorporate that feedback into a follow up proposal.
I am unclear how this could be implemented without ending up with a
ton of extra code that has to be maintained. pg_dump is a client-side
tool that does this; if we also have a server-side tool that does it,
then we have two things to maintain instead of one. I think that's
probably a non-trivial effort. I think you need to give some serious
thought to how to minimize that effort, and how to write tests that
will catch future problems without requiring everybody who ever makes
a DDL change ever again to test it against this functionality
specifically.
I would also like to complain that the original post of this thread
gave so little context that, unless you opened the patch, you wouldn't
have any idea what the thread was about. Ideally, the topic of a
thread should be evident from the subject line; where that is
impractical, it should be evident from the text of the first email; if
you have to open an attachment, that's not good. It may deprive people
who may have a strong opinion on the topic but limited time an
opportunity to notice that a discussion on that topic is occurring.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company