"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Also, what about foreign keys? At the moment it is incredibly complicated
> to determine all the foreign keys on a table, what column(s) they're defined
> over, what column(s) they reference and what their behaviour is. And just
> try writing code (like I am) that tries to drop them by name, let alone list
> them!!!
Indeed. You're looking at the aftermath of an "imperfect fix" to add
foreign keys. With all due respect to Jan and Stephan, who did a great
job adding the feature at all, there are still a lot of things that need
to be fixed in that area. The trouble with imperfect fixes is that they
tend to get institutionalized if they're left in the code for any length
of time --- people write more code that depends on the hack, or works
around some of its shortcomings, or whatever, and so it gets harder and
harder to rip out the hack and replace it with something better.
Especially if the original author moves on to other challenges instead
of continuing to work on improving his first try. Other people are
likely to have less understanding of the code's shortcomings.
I don't object to imperfect fixes when they buy us a useful amount of
functionality in a critical area (as indeed the current foreign-key code
does). But I have more of a problem with doing things that way for
marginal feature additions. I think that in the long run the downside
outweighs the upside in cases like that.
regards, tom lane
