On 23.06.2016 21:02, Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
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.
If you think those issues are not interrelated, you have not thought
about it carefully enough.
As an example, what we can do to handle not-expected-width fields is
very different if the format is "DDMMYY" versus if it is "DD-MM-YY".
In the first case we have little choice but to believe that each
field is exactly two digits wide. In the second case, depending on
how we decide to define matching of "-", we might be able to allow
the field widths to vary so that they're effectively "whatever is
between the dashes". But that would require insisting that "-"
match a "-", or at least a non-alphanumeric, which is not how it
behaves today.
I don't want to twiddle these behaviors in 9.6 and then again next year.
regards, tom lane
Hi,
I want to start work on this patch.
As a conclusion:
- need a decision about three questions:
* 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
- nobody wants solve this issue in 9.6.
And I have question: what about wrong input in date argument? For
example, from Alex's message:
postgres=# SELECT TO_TIMESTAMP('2016-02-30 15:43:36', 'YYYY-MM-DD
HH24:MI:SS');
to_timestamp
------------------------
2016-03-01 15:43:36+03
(1 row)
Here '2016-02-30' is wrong date. I didn't see any conclusion about this
case in the thread.
--
Artur Zakirov
Postgres Professional: http://www.postgrespro.com
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
