On Sun, May 14, 2023 at 2:20 AM Kirk Wolak <wol...@gmail.com> wrote:
> On Sat, May 13, 2023 at 3:34 PM Jeremy Smith <jer...@musicsmith.net>
> wrote:
>
>>
>>
>> On Sat, May 13, 2023, 3:25 AM Kirk Wolak <wol...@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...
