> 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.
What got me thinking about this is that I don't think my gram.y fix
would be accepted given the current review process, and that is bad
because we would have to live with no LIKE optimization for 1-2 years
until we learned how to do it right.
I think there are a few rules we can use to decide how to deal with
imperfect solutions:
Are the fixes easy to add _and_ easy to rip out later?Do the fixes affect all queries, or only queries that use the
feature?Dothe fixes adversely affect any older queries?Do the fixes make the system more unstable?
Foreign key is a good example of a fix that is hard to rip out. My
gram.y fix is an example of a fix that affects all queries. Fixes that
cause older queries or dumps to fail affect all users. I don't think we
have accepted fixes that adversely affect older queries or make the
system unstable because they are just too much trouble.
Let's look at the %TYPE fix as an example. It is easy to add and easy
to rip out. It doesn't affect all queries, just queries that use the
feature. It doesn't affect older queries. I think the only argument
against it is that it makes the system appear more unstable because
people may think that %TYPE is tracking table changes.
I am slightly concerned we are waiting for perfect solutions and
overlooking useful solutions.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
