On Feb 10, 2008, at 10:44 AM, Dave Livesay wrote:
I noticed that, in one of the third-party databases I have
installed on my server, one foreign key constraint could not be
implemented. (The key columns are of incompatible types.) In
previous upgrades I had seen a warning concerning this constraint,
and had passed this information along to the people who maintain
this database, but they ignored it. Now the warnings have turned
into an error, and the constraint isn't being implemented.
So this is an issue I've been aware of for a long time (more than
two years, in fact), and if I'd been responsible for maintaining
the database, I would have fixed it long ago.
Maybe I'm overly optimistic, but I get the impression that, if you
pay attention to warnings and fix your problems in a timely manner,
you're unlikely to be blindsided when the rules get tightened up in
subsequent releases.
True, however, there was never a "transitional" release that issued
warning when using implicit type casts in expressions like (heh):
some_timestamp_field LIKE '2008-01-02%'. I think having a
transitionary period in which warnings were emitted or having the
ability to switch the casting behavior on and off, much like what was
done with backslash escaped strings, would have made the change much
more appealing. For large applications that used the implicit type
casts a lot (and I even remember the implicit timestamp to string
casting being recommended usage on this list) being able to turn the
behaviour on and off on a per-session basis would have made the
migration LOADS simpler.
Erik Jones
DBA | Emma®
erik@xxxxxxxxxx
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
