On 23.06.2016 20:40, Tom Lane wrote:
Totally agree that we need more discussion about error handling in this
Robert Haas <robertmh...@gmail.com> writes:
On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston
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
Also this behavior is observed in to_date() and to_number() function:
postgres=# postgres=# select to_number('1$#@!!,2,%,%4,5,@%5@4..8-',
On the our side we have some discussions about to write a patch that
will change this incorrect behavior. So stay tuned.
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: