Re: "Strong sides of MySQL" talk from PgDay16Russia, translated

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

In response to

Browse pgsql-hackers by date

  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