Re: When MySQL Bites: Quirks to Watch Out For

On Wed, Aug 29, 2007 at 11:15:39AM -0400, Brian Hurt wrote:
>
> I was laughing because the alternative was crying.

I actually shed a tear when I read this part:

    But after all the above my preferred option is simply not to
    let MySQL get anywhere near my dates, storing everything as
    epoch seconds in integer fields, which can be stored and
    retrieved reasonably sanely and without giving MySQL a chance
    to fiddle with them -- it can't even tell they are dates!

"Oh!  Look!  Dates are broken!  So, I'll do all the date math myself
out in my application!"  No maintenance headaches there, for sure.  No
wonder MySQL is so popular with contract programmers: they can
guarantee years of income in the future just by working around
misfeatures in MySQL!

Perhaps PostgreSQL needs to introduce a GUC to control such
behaviours too.  Then we could be popular like that.  Here's a modest
proposal, with defaults set for present-day Postgres behaviour:

job_security_check_wholedate = true
job_security_check_dateparts = true
job_security_zerodate_sometimes_null = false
job_security_zerodate_sometimes_notnull = false
job_security_enforce_constraints = true
job_security_enforce_constraints_always = true
job_securty_enforce_constraints_bytable = false
job_security_ignore_foreign_keys = false
job_security_feature_subset_by_table = false

The problem with this proposal, of course, is that most of these
controls would be significant work to implement in Postgres, since
it's so rigid as to be unwilling to ignore the bad data you're trying
to put into its datatype, even though you "know what you're doing."
Obviously, Postgres was designed in the bad old days when programmers
thought they were gods; today, it'd be way more flexible.

Best regards,
A
--
Andrew Sullivan  | ajs@crankycanuck.ca
The plural of anecdote is not data.
        --Roger Brinner