Re: Adding SHOW CREATE TABLE

Kirk Wolak <wolakk@gmail.com>

From: Kirk Wolak <wolakk@gmail.com>
To: Jeremy Smith <jeremy@musicsmith.net>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Ron <ronljohnsonjr@gmail.com>, Stephen Frost <sfrost@snowman.net>, pgsql-general <pgsql-general@lists.postgresql.org>
Date: 2023-05-16T15:33:47Z
Lists: pgsql-hackers, pgsql-general
On Sun, May 14, 2023 at 2:20 AM Kirk Wolak <wolakk@gmail.com> wrote:

> On Sat, May 13, 2023 at 3:34 PM Jeremy Smith <jeremy@musicsmith.net>
> wrote:
>
>>
>>
>> On Sat, May 13, 2023, 3:25 AM Kirk Wolak <wolakk@gmail.com> wrote:
>>
>>> Does this imply SQL SYNTAX like:
>>>
>>> SHOW CREATE TABLE <table_name>
>>>   [ INCLUDING { ALL | INDEXES |  SEQUENCES | ??? }]
>>>   [EXCLUDING { PK | FK | COMMENTS | STORAGE | } ]
>>>   [FOR {V11 | V12 | V13 | V14 | V15 }] ??
>>> ?
>>>
>>
>> Personally, I would expect a function, like pg_get_tabledef(oid), to
>> match the other pg_get_*def functions instead of overloading SHOW.  To me,
>> this also argues that we shouldn't include indexes because we already have
>> a pg_get_indexdef function.
>>
>>       -Jeremy
>>
> +1
>
> In fact, making it a function will make my life easier for testing, that's
> for certain.  I don't need to involve the parser,etc.  Others can help with
> that after the function works.
> Thanks for the suggestion!
>

I am moving this over to the Hackers Group.
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).  This trivializes the approach,
and requires the smallest set of changes (psql is already close with
existing queries, etc).

And frankly, I would rather have an \st feature that handles 99% of the use
cases then go 15yrs waiting for a perfect solution.
Once this works well for the group.  Then, IMO, that would be the time to
discuss moving it.

Support Or Objections Appreciated.
Kirk...