Horton

Re: Retail DDL

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Isaac Morland <isaac.morland@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jelte Fennema-Nio <postgres@jeltef.nl>, Álvaro Herrera <alvherre@kurilemu.de>, Kirill Reshke <reshkekirill@gmail.com>, Ziga <ziga@ljudmila.org>, pgsql-hackers@lists.postgresql.org
Date: 2025-08-18T14:57:35Z
Lists: pgsql-hackers 
On 2025-08-18 Mo 10:39 AM, Isaac Morland wrote:
> On Mon, 18 Aug 2025 at 10:32, Andrew Dunstan <andrew@dunslane.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.


Sorry. I mean FK constraints on the table in question. I guess that's 
"from but not to", yes.


cheers


andrew


--
Andrew Dunstan
EDB:https://www.enterprisedb.com