| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
| Cc: | Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Ziga <ziga(at)ljudmila(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Retail DDL |
| Date: | 2025-08-19 08:19:55 |
| Message-ID: | fc51c27e4c0dedf6e855ba74e5ceb3e0ef3fbdd5.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2025-08-18 at 09:57 -0400, Tom Lane wrote:
> Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> writes:
>
> > I have wanted this MANY times. I've had this as a PG user: I think
> > it's literally the first thing I did when connecting to a Postgres
> > server the first time. Coming from MySQL, I wanted to see the exact
> > table definition, and there it was as easy as "DESCRIBE some_table".
>
> You haven't actually defined what "this" is. For starters, do you
> really want this output to be included in \d? Seems like one part
> or the other of such output would be clutter, so I'd be more minded
> to leave \d alone and invent some new command. (By analogy to \sf,
> maybe \st and so on?)
>
> But the real issue is what to print. In the case of a table, should
> we also show its indexes? What about foreign keys to or from other
> tables? If it's a partitioned table, what about the partitions?
> I'm not sure this is as simple as it seems.
Right, that is the hard problem.
We have had this discussion before, e.g. in
https://www.postgresql.org/message-id/flat/CAFEN2wxsDSSuOvrU03CE33ZphVLqtyh9viPp6huODCDx2UQkYA%40mail.gmail.com
Yours,
Laurenz Albe
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Man Zeng | 2025-08-19 08:24:01 | Re: When deleting the plpgsql function, release the CachedPlan of the function |
| Previous Message | Bertrand Drouvot | 2025-08-19 08:09:53 | Re: Improve LWLock tranche name visibility across backends |