From: | Artur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Alex Ignatov <a(dot)ignatov(at)postgrespro(dot)ru>, Bruce Momjian <bruce(at)momjian(dot)us>, amul sul <sul_amul(at)yahoo(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bug in to_timestamp(). |
Date: | 2016-07-14 09:05:58 |
Message-ID: | 734e50cd-c563-4afd-d1c8-80f244b3265e@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23.06.2016 21:02, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2016-07-14 09:16:34 | Re: Bug in to_timestamp(). |
Previous Message | Michael Paquier | 2016-07-14 08:41:27 | Re: Issue in pg_catalog.pg_indexes view definition |