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:

Previous
From: Jeff Davis
Date:
Subject: Re: ICU locale validation / canonicalization
Next
From: "David G. Johnston"
Date:
Subject: Re: Adding SHOW CREATE TABLE