|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().|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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 .
> * 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.
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
|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()|