From: | Arthur Zakirov <a(dot)zakirov(at)postgrespro(dot)ru> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, amul sul <sulamul(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "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: [HACKERS] Bug in to_timestamp(). |
Date: | 2018-02-12 11:49:45 |
Message-ID: | 20180212114943.GA6629@zakirov.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
On Fri, Feb 09, 2018 at 04:31:14PM +0100, Dmitry Dolgov wrote:
> I went through this thread, and want to summarize a bit:
>
> From what I see this patch addresses most important concerns that were
> mentioned in the thread, i.e. to make `to_timestamp` less confusing and be
> close to Oracles behavior. The code itself looks clear and sufficient, with the
> required documentation and green tests.
Thank you for reviewing!
> Looks like there are just two questions left so far:
>
> * I've noticed what I think a difference between current that was introduced in
> this patch and Oracle. In the following case we can have any number of spaces
> after a separator `+` in the input string
> ...
> But no spaces before it (it actually depends on how many separators do we have
> in the format string)
> ...
> Judging from this http://rextester.com/l/oracle_online_compiler in Oracle it's
> possible to have any number of spaces before or after `+` independently from
> the number of separators in an input string. Is it intended?
Yes, I somehow missed it. I changed the behaviour of separator
characters in format string. They are greedy now and eat whitespaces
before a separator character in an input string. I suppose that there
should be no such problems as in [1].
> * About usage of locale dependent functions e.g. `isalpha`. Yes, looks like
> it's better to have locale-agnostic implementation, but then I'm confused - all
> functions except `isdigit`/`isxdigit` are locale-dependent, including
> `isspace`, which is also in use.
I returned is_separator_char() function for now.
1 - https://www.postgresql.org/message-id/20180112125848.GA32559%40zakirov.localdomain
--
Arthur Zakirov
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
Attachment | Content-Type | Size |
---|---|---|
0001-to-timestamp-format-checking-v11.patch | text/plain | 12.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Rajkumar Raghuwanshi | 2018-02-12 12:30:24 | Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. |
Previous Message | Pavan Deolasee | 2018-02-12 11:03:51 | Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() |