4 ms·
Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.
by KingMob 11y ago
Which is why it was a great fit for MySQL, which would silently store invalid dates and truncate over-long strings with no warnings.
- vog 11y agoThis is so true. It is the main reason I switched to PostgreSQL and never looked back.
- gmac 11y ago... and accept nonsensical SQL queries, returning whatever it feels like.
- mratzloff 11y agoYou joke, but I'm pretty sure this is one of the reasons why that stack was so successful. Same principle behind HTML rendering. "It's displaying something, isn't it? Errors are only suggestions."
- krick 11y agoI'm not so sure. It's kind of true for HTML (forgiveness was not "good" property of the format, but of the browser: 1 site works in one browser, but not in the other, and user will blame the browser, so let's display whatever the hell we can). But PHP in the early days was kinda handy (even though hacky) tool, allowing to use simple syntax to render HTML instead of custom Perl-scripts. And then it just got popular. MySQL was once actually superior open-source database, being more performant and simpler to setup and use than PostgreSQL. And then, once again, it just got popular. I don't think being faulty helped these technologies, although it sometimes is the case.
- k_roy 11y agoThere are warnings. Most people just ignore them in their APIs
- KingMob 11y agoTrying to insert over-large data should have been an error by default from the outset, never a warning. Ilooked at MySQL in 2000 and went "You had one job, database; protect my data."