Robert Haas <robertmh...@gmail.com> writes: > I don't have any complaint about labelling some of the unique indexes > as primary keys, but I think installing foreign keys that don't really > enforce anything may lead to confusion.
I'm not sure if I buy the "confusion" argument, but after thinking about this more I realized that there's a stronger roadblock for treating catalog interrelationships as SQL foreign keys. Namely, that we always represent no-reference situations with a zero OID, whereas it'd have to be NULL to look like a valid foreign-key case. Changing to real NULLs in those columns would of course break a ton of C code, so I don't think that's gonna happen. We could overlay an FK onto OID columns that should never have zero entries, but that would miss enough of the interesting cases that I don't find it a very attractive proposal. So I think we should finish up the project of making real SQL constraints for the catalog indexes, but the idea of making FK constraints too looks like it'll end in failure. The reason I got interested in this right now is the nearby discussion [1] about why findoidjoins misses some catalog relationships and whether we should fix that and/or make its results more readily accessible. I'd thought perhaps FK constraint entries could supersede the need for that tool altogether, but now it seems like not. I still like the idea of marking OID relationships in the catalog headers though. Perhaps we should take Joel's suggestion of a new system catalog more seriously, and have genbki.pl populate such a catalog from info in the catalog header files. regards, tom lane [1] https://www.postgresql.org/message-id/flat/d1f413ff-0e50-413d-910c-bdd9ee9752c1%40www.fastmail.com