Re: Bug in to_timestamp().
От | Artur Zakirov |
---|---|
Тема | Re: Bug in to_timestamp(). |
Дата | |
Msg-id | 734e50cd-c563-4afd-d1c8-80f244b3265e@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: Bug in to_timestamp(). (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Bug in to_timestamp().
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: