From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | David Fetter <david(at)fetter(dot)org>, 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:54:43 |
Message-ID: | 0437b229-4f88-353f-902c-a34df11b5cdc@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/29/16 3:13 PM, David Fetter wrote:
> 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?
This particular case is probably not hard, but the problem is that that
would raise the bar about error pointer precision, and you then should
also update a bunch of other places to give similar precision. That
could be a lot of work.
I am, however, of the opinion, that these kinds of things can never be
helpful enough. The latest trend is start and end pointers, which would
be nice.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-07-29 20:08:00 | Re: Design for In-Core Logical Replication |
Previous Message | Tom Lane | 2016-07-29 19:37:17 | Performance of tqueue.c's tuple remapping logic |