| From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>, Kirill Reshke <reshkekirill(at)gmail(dot)com>, Ziga <ziga(at)ljudmila(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Retail DDL |
| Date: | 2025-08-18 14:39:37 |
| Message-ID: | CAMsGm5dx6Ux0nvzsVDRao=gO+BEbZuHkFGDVDuPf6vhkT8tK+w@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
> > 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.
>
> Agreed it's not simple, but that doesn't mean we should not do it.
> Tables are the most obviously complex case. I'm inclined to say foreign
> keys to but not from, and also include indexes. But maybe we can provide
> several flavors, by allowing some function options, e.g.
>
Are you sure you don't mean from but not to?
If I want foreign keys from a table when looking at that table's
definition, they can be part of a single CREATE TABLE statement. If I want
foreign keys to that table, I need a bunch of ALTER TABLE statements naming
the other tables whose foreign keys point at the table in question.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2025-08-18 14:49:56 | Re: Parallel Apply |
| Previous Message | Andrew Dunstan | 2025-08-18 14:32:38 | Re: Retail DDL |