On 2025-08-18 Mo 10:39 AM, Isaac Morland 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
