On 23.06.2016 20:40, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
<david.g.johns...@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');
(1 row)

postgres=# postgres=# select to_number('1$#@!!,2,%,%4,5,@%5@4..8-', '999G999D9S');
(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:

Reply via email to