Thread: SHOW CREATE
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
Attachment
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.
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 specificcommands for them? It seems they would potentially more useful as functions, where they'd be available for all ofthe 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