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@myemma.com
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