From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | 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-06-20 12:19:12 |
Message-ID: | CA+TgmoZKJOoywaBT-K_pmQT4yPuDmR5AxjcEdwiCofA5Q3S0yA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> amul sul <sul_amul(at)yahoo(dot)co(dot)in> writes:
>>> It's look like bug in to_timestamp() function when format string has more whitespaces compare to input string, see below:
>>
>> No, I think this is a case of "input doesn't match the format string".
>>
>> As a rule of thumb, using to_timestamp() for input that could be parsed
>> just fine by the standard timestamp input function is not a particularly
>> good idea. to_timestamp() is meant to deal with input that is in a
>> well-defined format that happens to not be parsable by timestamp_in.
>> This example doesn't meet either of those preconditions.
>
> I think a space in the format string should skip a whitespace
> character in the input string, but not a non-whitespace character.
> It's my understanding that these functions exist in no small part for
> compatibility with Oracle, and Oracle declines to skip the digit '1'
> on the basis of an extra space in the format string, which IMHO is the
> behavior any reasonable user would expect.
So Amul and I are of one opinion and Tom is of another. Anyone else
have an opinion?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-06-20 12:58:23 | Re: Bug in to_timestamp(). |
Previous Message | Asif Naeem | 2016-06-20 11:28:38 | Re: Truncating/vacuuming relations on full tablespaces |