Subject: Re: Bug in to_timestamp().
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
References: 
 <1873520224.1784572.1465833145330.JavaMail.yahoo.ref@mail.yahoo.com>
 <1873520224.1784572.1465833145330.JavaMail.yahoo@mail.yahoo.com>
 <f64563b3-5c3c-6f28-3f73-41b2159417bc@postgrespro.ru>
 <884791796.213185.1466667686999.JavaMail.yahoo@mail.yahoo.com>
 <20160623133001.GF21246@momjian.us>
 <1877e60a-a970-18b5-453c-e342f96150e6@postgrespro.ru>
 <CAKFQuwZKtS0Ad=a1E9_mkdYwLMq+JA3YjmhCvjJ1JF+3BU8a0g@mail.gmail.com>
 <d469b177-fd4d-5a5b-769e-620957ec1a64@postgrespro.ru>
 <CAKFQuwb2gp8n2ai_agyJod5BTYxL7ek0AjB9zifDSceK6QntnQ@mail.gmail.com>
 <CA+TgmoaWTgbtd2RTwVvySMVoOcHmWq66rCCxtVywOOX3FJy4tQ@mail.gmail.com>
 <31915.1466703655@sss.pgh.pa.us>
 <CA+TgmoaFQZeqmAo3CdivNu70coB=9eM5OroKYtNcTuMaC1kuUQ@mail.gmail.com>
 <32684.1466704957@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Alex Ignatov <a.ignatov@postgrespro.ru>, Bruce Momjian <bruce@momjian.us>,
 amul sul <sul_amul@yahoo.co.in>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
From: Artur Zakirov <a.zakirov@postgrespro.ru>
Message-ID: <734e50cd-c563-4afd-d1c8-80f244b3265e@postgrespro.ru>
Date: Thu, 14 Jul 2016 12:05:58 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <32684.1466704957@sss.pgh.pa.us>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 23.06.2016 21:02, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane <tgl@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