Re: Bug in to_timestamp().

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

In response to

Responses

Browse pgsql-hackers by date

  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