From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Kirk Wolak <wolakk(at)gmail(dot)com> |
Cc: | Jeremy Smith <jeremy(at)musicsmith(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Ron <ronljohnsonjr(at)gmail(dot)com> |
Subject: | Re: Adding SHOW CREATE TABLE |
Date: | 2023-05-18 23:53:58 |
Message-ID: | ZGa6lrLlZVIarDK4@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
Greetings,
* Kirk Wolak (wolakk(at)gmail(dot)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). 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.
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..
Using libpq would also make sense from the perspective that libpq can be
used to connect to a number of different major versions of PG and this
could work work for them all in much the way that pg_dump does.
The downside with this apporach is that drivers which don't use libpq
(eg: JDBC) would have to re-implement this if they wanted to keep
feature parity with libpq..
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2023-05-19 04:02:06 | Re: PostgreSQL 13 - Logical Replication - ERROR: could not receive data from WAL stream: SSL SYSCALL error: EOF detected |
Previous Message | Stephen Frost | 2023-05-18 23:47:00 | Re: Would PostgreSQL 16 native transparent data encryption support database level encryption? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-05-18 23:57:14 | Re: The documentation for READ COMMITTED may be incomplete or wrong |
Previous Message | Matthias van de Meent | 2023-05-18 23:47:51 | Re: XLog size reductions: smaller XLRec block header for PG17 |