Subject: Re: Bug in to_timestamp().
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
References: 
 <1873520224.1784572.1465833145330.JavaMail.yahoo.ref@mail.yahoo.com>
 <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com>
 <f64563b3-5c3c-6f28-3f73-41b2159417bc@postgrespro.ru>
 <884791796.213185.1466667686999.JavaMail.yahoo@mail.yahoo.com>
 <20160623133001.GF21246@momjian.us>
 <1877e60a-a970-18b5-453c-e342f96150e6@postgrespro.ru>
 <CAKFQuwZKtS0Ad=a1E9_mkdYwLMq+JA3YjmhCvjJ1JF+3BU8a0g@mail.gmail.com>
 <d469b177-fd4d-5a5b-769e-620957ec1a64@postgrespro.ru>
 <CAKFQuwb2gp8n2ai_agyJod5BTYxL7ek0AjB9zifDSceK6QntnQ@mail.gmail.com>
 <CA+TgmoaWTgbtd2RTwVvySMVoOcHmWq66rCCxtVywOOX3FJy4tQ@mail.gmail.com>
 <31915.1466703655@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Bruce Momjian <bruce@momjian.us>, amul sul <sul_amul@yahoo.co.in>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
From: Alex Ignatov <a.ignatov@postgrespro.ru>
Message-ID: <4bb0a571-2211-7c97-0826-dfaf20cc9e21@postgrespro.ru>
Date: Fri, 24 Jun 2016 18:41:46 +0300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <31915.1466703655@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


On 23.06.2016 20:40, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
>> <david.g.johnston@gmail.com> wrote:
>>> My understanding is that is not going to change for 9.6.
>> That's exactly what is under discussion here.
> I would definitely agree with David on that point.  Making to_timestamp
> noticeably better on this score seems like a nontrivial project, and
> post-beta is not the time for that sort of thing, even if we had full
> consensus on what to do.  I'd suggest somebody work on a patch and put
> it up for review in the next cycle.
>
> Now, if you were to narrowly define the problem as "whether to skip
> non-spaces for a space in the format", maybe that could be fixed
> post-beta, but I think that's a wrongheaded approach.  to_timestamp's
> issues with input that doesn't match the format are far wider than that.
> IMO we should try to resolve the whole problem with one coherent change,
> not make incremental incompatible changes at the margins.
>
> At the very least I'd want to see a thought-through proposal that
> addresses all three of these interrelated points:
>
> * what should a space in the format match
> * what should a non-space, non-format-code character in the format match
> * how should we handle fields that are not exactly the width suggested
> by the format
>
> 			regards, tom lane
>
>
Totally agree that we need more discussion about error handling in this 
function!

Also this behavior is observed in to_date() and to_number() function:

postgres=# SELECT 
TO_DATE('2!0!1!6----!0!6-/-/-/-/-/-/-1!/-/-/-/-/-/-/-3!', 'YYYY-MM-DD');
   to_date
------------
  0002-01-01
(1 row)

postgres=# postgres=# select to_number('1$#@!!,2,%,%4,5,@%5@4..8-', 
'999G999D9S');
  to_number
-----------
         12
(1 row)

On the our side we have some discussions about to write a patch that 
will change this incorrect  behavior. So stay tuned.

-- 

Alex Ignatov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers