From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: "Strong sides of MySQL" talk from PgDay16Russia, translated |
Date: | 2016-07-29 19:13:56 |
Message-ID: | 20160729191356.GE4953@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 29, 2016 at 09:20:12PM +0300, Nikolay Samokhvalov wrote:
> On Fri, Jul 29, 2016 at 5:28 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
> >
> > The way I sum up MySQL vs PG for people that ask is to recount how they
> > "fixed" the Feb. 31st bug when they released strict mode (something that
> > they actually called out in the release PR). With strict mode enabled, Feb.
> > 30th and 31st would give you an error. Feb 35th was still silently
> > converted to March whatever. *That was the MySQL mentality: data quality
> > doesn't matter compared to "ease of use".*
> >
> > They've done this throughout their history... when presented with a hard
> > problem, they skip around it or plaster over it, and then they promote that
> > their solution is the only right way to solve the problem. (Their docs
> > actually used to say that anything other that table-level locking was a bad
> > idea.)
>
>
> This is exactly what I mean saying MySQL speaks different language than I
> know, and that's why I simply cannot use it:
>
> (mysql 5.7.12)
>
> mysql> select cast('2016-99-99' as date);
> +----------------------------+
> | cast('2016-99-99' as date) |
> +----------------------------+
> | NULL |
> +----------------------------+
> 1 row in set, 1 warning (0.00 sec)
>
>
> In Postgres:
>
> test=# select cast('2016-99-99' as date);
> ERROR: date/time field value out of range: "2016-99-99"
> LINE 1: select cast('2016-99-99' as date);
> ^
I expect this kind of blather from MySQL, but you've brought up
something that's been bothering me for awhile. PostgreSQL's response
should look more like this:
ERROR: month field value out of range: "2016-99-99"
LINE 1: select cast('2016-99-99' as date);
^
Any idea how much effort that would be?
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-29 19:37:17 | Performance of tqueue.c's tuple remapping logic |
Previous Message | Stephen Frost | 2016-07-29 18:36:45 | Re: Why we lost Uber as a user |