Thread: When MySQL Bites: Quirks to Watch Out For
http://use.perl.org/~Smylers/journal/34246 -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: kaare@jasonic.dk
> > http://use.perl.org/~Smylers/journal/34246 > > -- > The biggest quirk is that in version 4.1 and above, you can disable or enable this "quirk-mode" at will. You can get consistent behaviour if you want it... if you don't, just disable it...
On 8/29/07, vincent <vinny@xs4all.nl> wrote: > The biggest quirk is that in version 4.1 and above, you can disable or > enable this "quirk-mode" at will. You can get consistent behaviour if you > want it... if you don't, just disable it... Yep. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Kaare Rasmussen wrote: > > http://use.perl.org/~Smylers/journal/34246 Got a chuckle here on how allballs is both NULL and NOT NULL simultaneously ... -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
I was laughing because the alternative was crying.
Brian
I was chuckling at the point where data intergrity is "quaint and old-fasioned".Kaare Rasmussen wrote:http://use.perl.org/~Smylers/journal/34246Got a chuckle here on how allballs is both NULL and NOT NULL simultaneously ...
I was laughing because the alternative was crying.
Brian
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
Andrew Sullivan wrote: >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: > > > LOL. At least, I hope that was a joke. Brian
No. I guess we'll have a thread of 150 messages talking how we name this feature ;-) Rgs, Jussi Brian Hurt wrote: > Andrew Sullivan wrote: > >> 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: >> >> >> > > LOL. > > At least, I hope that was a joke. > > Brian > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
Wow - multiple values simultaneously - that's quantum computing! On 8/30/07, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Kaare Rasmussen wrote: > > > > http://use.perl.org/~Smylers/journal/34246 > > Got a chuckle here on how allballs is both NULL and NOT NULL > simultaneously ... > > -- > Alvaro Herrera http://www.CommandPrompt.com/ > PostgreSQL Replication, Consulting, Custom Development, 24x7 support > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Mark Aufflick contact info at http://mark.aufflick.com/about/contact