| From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SHOW CREATE |
| Date: | 2019-07-13 23:32:41 |
| Message-ID: | AD031B6B-6CF0-4302-847B-633058AB66B5@seespotcode.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 2019–07–05, at 12:14, Corey Huinker <corey(dot)huinker(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2019-07-13 23:44:52 | Re: Avoiding hash join batch explosions with extreme skew and weird stats |
| Previous Message | Karl O. Pinc | 2019-07-13 22:03:37 | Re: Patch to document base64 encoding |