On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <t...@sss.pgh.pa.us> 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
I'm not averse to some further study of those issues, and I think the first two are closely related. The third one strikes me as a somewhat separate consideration that doesn't need to be addressed by the same patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
