Re: Adding SHOW CREATE TABLE - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: Adding SHOW CREATE TABLE |
Date | |
Msg-id | ZGkCxT614Kg4emrs@tamriel.snowman.net Whole thread Raw |
In response to | Re: Adding SHOW CREATE TABLE (Laurenz Albe <laurenz.albe@cybertec.at>) |
Responses |
Re: Adding SHOW CREATE TABLE
|
List | pgsql-hackers |
Greetings, * Laurenz Albe (laurenz.albe@cybertec.at) wrote: > On Fri, 2023-05-19 at 13:08 -0400, Andrew Dunstan wrote: > > On 2023-05-18 Th 19:53, Stephen Frost wrote: > > > * Kirk Wolak (wolakk@gmail.com) wrote: > > > > My approach for now is to develop this as the \st command. > > > > After reviewing the code/output from the 3 sources (psql, fdw, and > > > > pg_dump). > > > > > > Having this only available via psql seems like the least desirable > > > option as then it wouldn't be available to any other callers.. > > > > > > Having it in libpq, on the other hand, would make it available to psql > > > as well as any other utility, library, or language / driver which uses > > > libpq, including pg_dump.. > > > > I think the ONLY place we should have this is in server side functions. > > +1 ... but it already exists in pg_dump, so I'm unclear why folks seem to be pushing to have a duplicate of it in core? We certainly can't remove it from pg_dump even if we add it to core because pg_dump has to understand the changes between major versions. > A function "pg_get_tabledef" would blend nicely into the following list: > > \df pg_get_*def > List of functions > Schema │ Name │ Result data type │ Argument data types │ Type > ════════════╪════════════════════════════════╪══════════════════╪═══════════════════════╪══════ > pg_catalog │ pg_get_constraintdef │ text │ oid │ func > pg_catalog │ pg_get_constraintdef │ text │ oid, boolean │ func > pg_catalog │ pg_get_functiondef │ text │ oid │ func > pg_catalog │ pg_get_indexdef │ text │ oid │ func > pg_catalog │ pg_get_indexdef │ text │ oid, integer, boolean │ func > pg_catalog │ pg_get_partition_constraintdef │ text │ oid │ func > pg_catalog │ pg_get_partkeydef │ text │ oid │ func > pg_catalog │ pg_get_ruledef │ text │ oid │ func > pg_catalog │ pg_get_ruledef │ text │ oid, boolean │ func > pg_catalog │ pg_get_statisticsobjdef │ text │ oid │ func > pg_catalog │ pg_get_triggerdef │ text │ oid │ func > pg_catalog │ pg_get_triggerdef │ text │ oid, boolean │ func > pg_catalog │ pg_get_viewdef │ text │ oid │ func > pg_catalog │ pg_get_viewdef │ text │ oid, boolean │ func > pg_catalog │ pg_get_viewdef │ text │ oid, integer │ func > pg_catalog │ pg_get_viewdef │ text │ text │ func > pg_catalog │ pg_get_viewdef │ text │ text, boolean │ func > (17 rows) > > > A server function can be conveniently called from any client code. Clearly any client using libpq can conveniently call code which is in libpq. Thanks, Stephen
Attachment
pgsql-hackers by date: