Re: [HACKERS] Bug in to_timestamp().

On 2/27/17 4:19 AM, Artur Zakirov wrote: > On 15.02.2017 15:26, Amul Sul wrote: >> >> The new status of this patch is: Ready for Committer >> > > Thank you for your review! This submission has been moved to CF 2017-07. -- -David da...@pgmasters.net -- Sent via pgsql-hackers mailing list

Re: [HACKERS] Bug in to_timestamp().

On 15.02.2017 15:26, Amul Sul wrote: The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Review of v7 patch: - Patch

Re: [HACKERS] Bug in to_timestamp().

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Review of v7 patch: - Patch applies to the top of master HEAD

Re: [HACKERS] Bug in to_timestamp().

On Mon, Dec 5, 2016 at 11:35 AM, Haribabu Kommi wrote: > Moved to next CF with "needs review" status. Same, this time to CF 2017-03. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Bug in to_timestamp().

On Mon, Nov 7, 2016 at 2:26 AM, Artur Zakirov wrote: > > Hm, truly. Fixed it. > > I've attached the fixed patch. > Moved to next CF with "needs review" status. Regards, Hari Babu Fujitsu Australia

Re: [HACKERS] Bug in to_timestamp().

Thank you for your comments, 2016-11-04 20:36 GMT+02:00 Tom Lane : > > Artur Zakirov writes: > > I attached new version of the patch, which fix is_char_separator() > > declaration too. > > I did some experimenting using >

Re: [HACKERS] Bug in to_timestamp().

Artur Zakirov writes: > I attached new version of the patch, which fix is_char_separator() > declaration too. I did some experimenting using http://rextester.com/l/oracle_online_compiler It appears that Oracle will consider a single space in the pattern to match zero

Re: [HACKERS] Bug in to_timestamp().

On Fri, Sep 30, 2016 at 12:34 PM, Amul Sul wrote: > The new status of this patch is: Ready for Committer And moved to next CF with same status. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Bug in to_timestamp().

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed Appreciate your support. I've tested v6 patch again, looks good

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote: >> Commitfest status left untouched, I am not sure how to deal with >> "Returned With Feedback" patch. Is there any chance that, this can be >> considered again for committer review?

Re: [HACKERS] Bug in to_timestamp().

On Thu, Sep 29, 2016 at 4:54 AM, amul sul wrote: > On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: >> Artur Zakirov writes: >>> - now DCH_cache_getnew() is called after parse_format(). Because now >>> parse_format() can raise an

Re: [HACKERS] Bug in to_timestamp().

2016-09-29 13:54 GMT+05:00 amul sul : > > On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: > > > > I started looking at your 0001-to-timestamp-format-checking-v4.patch > > and this point immediately jumped out at me. Currently the code relies > > ...

Re: [HACKERS] Bug in to_timestamp().

On Thu, Sep 29, 2016 at 2:48 AM, Tom Lane wrote: > Artur Zakirov writes: >> - now DCH_cache_getnew() is called after parse_format(). Because now >> parse_format() can raise an error and in the next attempt >> DCH_cache_search() could return broken

Re: [HACKERS] Bug in to_timestamp().

Artur Zakirov writes: > - now DCH_cache_getnew() is called after parse_format(). Because now > parse_format() can raise an error and in the next attempt > DCH_cache_search() could return broken cache entry. I started looking at your

Re: [HACKERS] Bug in to_timestamp().

On Fri, Sep 16, 2016 at 10:01 PM, Artur Zakirov wrote: > On 25.08.2016 13:26, amul sul wrote: >>> >>> Thanks. I've created the entry in >>> https://commitfest.postgresql.org/10/713/ >>> . You can add yourself as a reviewer. >>> >> >> Done, added myself as reviewer &

Re: [HACKERS] Bug in to_timestamp().

On 25.08.2016 13:26, amul sul wrote: Thanks. I've created the entry in https://commitfest.postgresql.org/10/713/ . You can add yourself as a reviewer. Done, added myself as reviewer & changed status to "Ready for Committer". Thanks ! Regards, Amul Sul It seems there is no need to rebase

Re: [HACKERS] Bug in to_timestamp().

On Thu, Aug 25, 2016 at 3:41 PM, Artur Zakirov wrote: >>> You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to >>> execute such query: >>> >>> >>> SELECT to_timestamp('---2000JUN', ' MON'); >>> >>> >>> Will be it a proper behaviour? >> >> >> >>

Re: [HACKERS] Bug in to_timestamp().

You are right. I assigned to prev_type NODE_TYPE_SPACE to be able to execute such query: SELECT to_timestamp('---2000JUN', ' MON'); Will be it a proper behaviour? Looks good to me, no one will complain if something working on PG but not on Oracle. Thanks. I've created the entry

Re: [HACKERS] Bug in to_timestamp().

On Thursday, August 25, 2016 1:56 PM, Artur Zakirov wrote: >> #2. Warning at compilation; >> >> formatting.c: In function ‘do_to_timestamp’: >> formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized in this >> function [-Wmaybe-uninitialized] >> if

Re: [HACKERS] Bug in to_timestamp().

Hi, #1. Whitespace @ line # 317. Sorry, fixed. #2. Warning at compilation; formatting.c: In function ‘do_to_timestamp’: formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized in this function [-Wmaybe-uninitialized] if (prev_type == NODE_TYPE_SPACE || prev_type ==

Re: [HACKERS] Bug in to_timestamp().

Hi Artur Zakirov, 0001-to-timestamp-format-checking-v3.patch looks pretty reasonable to me, other than following concern: #1. Whitespace @ line # 317. #2. Warning at compilation; formatting.c: In function ‘do_to_timestamp’: formatting.c:3049:37: warning: ‘prev_type’ may be used uninitialized

Re: [HACKERS] Bug in to_timestamp().

Sorry. I did not get last two mails from Amul. Don't know why. So I reply to another mail. Documented as working case, but unfortunatly it does not : postgres=# SELECT to_timestamp('2000JUN', ' MON'); ERROR: invalid value "---" for "MON" DETAIL: The given value did not match any of

Re: [HACKERS] Bug in to_timestamp().

Hi Artur Zakirov, Please see following review comment for "0001-to-timestamp-format-checking-v2.patch" & share your thought: #1. 15 + to_timestamp('2000JUN', ' MON') Documented as working case, but unfortunatly it does not : postgres=# SELECT to_timestamp('2000JUN', '

Re: [HACKERS] Bug in to_timestamp().

On Friday, August 19, 2016 12:42 AM, Robert Haas wrote: >On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote: > > >> Hmm. I haven't really looked into the code, but with applying both patches >> it looks precisely imitate Oracle's behaviour. Thanks. >

Re: [HACKERS] Bug in to_timestamp().

On Wed, Aug 17, 2016 at 10:35 AM, amul sul wrote: > Hmm. I haven't really looked into the code, but with applying both patches it > looks precisely imitate Oracle's behaviour. Thanks. This is good to hear, but for us to consider applying something like this, somebody would

Re: [HACKERS] Bug in to_timestamp().

On Wednesday, August 17, 2016 5:15 PM, Artur Zakirov wrote: >I attached new patch "0001-to-timestamp-format-checking-v2.patch". It >fixes behaviour for Amul's scenarious: > Great. > >> Following are few scenarios where we break existing behaviour: >> >> SELECT

Re: [HACKERS] Bug in to_timestamp().

I attached new patch "0001-to-timestamp-format-checking-v2.patch". It fixes behaviour for Amul's scenarious: Following are few scenarios where we break existing behaviour: SELECT TO_TIMESTAMP('2015-12-31 13:43:36', ' MM DD HH24 MI SS'); SELECT TO_TIMESTAMP('2011$03!18 23_38_15',

Re: [HACKERS] Bug in to_timestamp().

On 15.08.2016 19:28, Robert Haas wrote: Well, what's the Oracle behavior in any of these cases? I don't think we can decide to change any of this behavior without knowing that. If a proposed behavior change is incompatible with our previous releases, I think it'd better at least be more

Re: [HACKERS] Bug in to_timestamp().

Monday, 15 August 2016 9:58 PM, Robert Haas wrote: >On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote: >> On Thursday, 11 August 2016 3:18 PM, Artur Zakirov >> wrote: [Skipped..] >Well, what's the Oracle behavior in any of

Re: [HACKERS] Bug in to_timestamp().

On Mon, Aug 15, 2016 at 10:56 AM, amul sul wrote: > On Thursday, 11 August 2016 3:18 PM, Artur Zakirov > wrote: > >>Here is my patch. It is a proof of concept. >>Date/Time Formatting >> >>There are changes in date/time

Re: [HACKERS] Bug in to_timestamp().

On Thursday, 11 August 2016 3:18 PM, Artur Zakirov wrote: >Here is my patch. It is a proof of concept.>Date/Time >Formatting>>There are changes in date/time formatting >rules:-> now to_timestamp() and to_date() skip spaces in the input string and 

Re: [HACKERS] Bug in to_timestamp().

Hello, On 14.07.2016 12:16, Pavel Stehule wrote: last point was discussed in thread related to to_date_valid function. Regards Pavel Thank you. Here is my patch. It is a proof of concept. Date/Time Formatting There are changes in date/time formatting rules: - now

Re: [HACKERS] Bug in to_timestamp().

2016-07-14 11:05 GMT+02:00 Artur Zakirov : > On 23.06.2016 21:02, Tom Lane wrote: > >> Robert Haas writes: >> >>> On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote: >>> At the very least I'd want to see a thought-through

Re: [HACKERS] Bug in to_timestamp().

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

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 02:00:49PM -0400, Robert Haas wrote: > > Ok. I'm having trouble seeing this justified as a bug fix - the docs > > clearly state our behavior is intentional. Improved behavior, yes, but > > that's a feature and we're in beta2. Please be specific if you believe I've > >

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 5:16 PM, Tom Lane wrote: > Robert Haas writes: >> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford >> wrote: >>> To me, 2016-02-30 is an invalid date that should generate an error. > >> I don't

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 3:43 PM, Joshua D. Drake wrote: > On 06/24/2016 02:16 PM, Tom Lane wrote: > >> Robert Haas writes: >> >>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford >>> wrote: >>> To me,

Re: [HACKERS] Bug in to_timestamp().

On 06/24/2016 02:16 PM, Tom Lane wrote: Robert Haas writes: On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: To me, 2016-02-30 is an invalid date that should generate an error. I don't particularly disagree with that, but on

Re: [HACKERS] Bug in to_timestamp().

On 25/06/16 08:33, Robert Haas wrote: On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford > wrote: >> To me, 2016-02-30 is an invalid date that should generate an error. > I don't particularly disagree with that, but on the other hand, as > mentioned earlier,

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford wrote: > My observation has been that the PostgreSQL development group aims for > correctness and the elimination of surprising results. This was part of the > reason to eliminate a number of automatic casts to dates

Re: [HACKERS] Bug in to_timestamp().

On 06/24/2016 09:26 AM, Steve Crawford wrote: My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a number of automatic casts to dates in earlier versions. To me, 2016-02-30 is an

Re: [HACKERS] Bug in to_timestamp().

My observation has been that the PostgreSQL development group aims for correctness and the elimination of surprising results. This was part of the reason to eliminate a number of automatic casts to dates in earlier versions. To me, 2016-02-30 is an invalid date that should generate an error.

Re: [HACKERS] Bug in to_timestamp().

Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 20.06.2016 17:09, Albe Laurenz wrote: Tom Lane wrote: I don't necessarily have an opinion yet. I would like to see more than just an unsupported assertion about what Oracle's behavior is. Also,

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 20:40, Tom Lane wrote: Robert Haas writes: On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston wrote: My understanding is that is not going to change for 9.6. That's exactly what is under discussion here. I would definitely

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 2:00 PM, Robert Haas wrote: > On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston > wrote: > >> Sheesh. Who put you in charge of this? You basically seem like you > >> are trying to shut up anyone who supports this

Re: [HACKERS] Bug in to_timestamp().

On 6/23/16 12:29 PM, Alvaro Herrera wrote: David G. Johnston wrote: On Thursday, June 23, 2016, Alex Ignatov wrote: Arguing just like that one can say that we don't even need exception like "division by zero". Just use well-formed numbers in denominator... Input

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane 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

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:46 PM, David G. Johnston wrote: >> Sheesh. Who put you in charge of this? You basically seem like you >> are trying to shut up anyone who supports this change, and I don't >> think that's right. > > I'm all for a change in this area - though

Re: [HACKERS] Bug in to_timestamp().

On Thursday, June 23, 2016, Robert Haas wrote: > On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston > > wrote: > > to_timestamp with its present behavior is, IMO, a poorly designed > function > > that would never be accepted today.

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:40 PM, Tom Lane wrote: > Robert Haas writes: >> On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston >> wrote: >>> My understanding is that is not going to change for 9.6. > >> That's exactly what is

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston > wrote: >> My understanding is that is not going to change for 9.6. > That's exactly what is under discussion here. I would definitely agree with David on that point.

Re: [HACKERS] Bug in to_timestamp().

David G. Johnston wrote: > On Thursday, June 23, 2016, Alex Ignatov wrote: > > > Arguing just like that one can say that we don't even need exception like > > "division by zero". Just use well-formed numbers in denominator... > > Input data sometimes can be generated

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 1:12 PM, David G. Johnston wrote: > to_timestamp with its present behavior is, IMO, a poorly designed function > that would never be accepted today. Concrete proposals for either fixing or > deprecating (or both) are welcome. Fixing it should

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 12:37 PM, David G. Johnston wrote > To be honest I don't see how this is relevant to quoted content. And you've > already made this point quite clearly - repeating it isn't constructive. > This behavior has existed for a long time and I don't

Re: [HACKERS] Bug in to_timestamp().

On Thursday, June 23, 2016, Alex Ignatov wrote: > Arguing just like that one can say that we don't even need exception like > "division by zero". Just use well-formed numbers in denominator... > Input data sometimes can be generated automagically. Without exception >

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 19:37, David G. Johnston wrote: On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov >wrote: On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: On

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 12:16 PM, Alex Ignatov wrote: > > On 23.06.2016 16:30, Bruce Momjian wrote: > >> On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: >> >>> On Monday, 20 June 2016 8:53 PM, Alex Ignatov >>> wrote: >>> >>> >>> On

Re: [HACKERS] Bug in to_timestamp().

On 23.06.2016 16:30, Bruce Momjian wrote: On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote: On 13.06.2016 18:52, amul sul wrote: And it wont stop on some simple whitespace. By using to_timestamp you can

Re: [HACKERS] Bug in to_timestamp().

On Thu, Jun 23, 2016 at 07:41:26AM +, amul sul wrote: > On Monday, 20 June 2016 8:53 PM, Alex Ignatov > wrote: > > > >>On 13.06.2016 18:52, amul sul wrote: > >And it wont stop on some simple whitespace. By using to_timestamp you > >can get any output results by

Re: [HACKERS] Bug in to_timestamp().

On Monday, 20 June 2016 8:53 PM, Alex Ignatov wrote: >>On 13.06.2016 18:52, amul sul wrote: >And it wont stop on some simple whitespace. By using to_timestamp you >can get any output results by providing illegal input parameters values: >postgres=# SELECT

Re: [HACKERS] Bug in to_timestamp().

On 13.06.2016 18:52, amul sul wrote: Hi, It's look like bug in to_timestamp() function when format string has more whitespaces compare to input string, see below: Ex.1: Two white spaces before HH24 whereas one before input time string postgres=# SELECT TO_TIMESTAMP('2016-06-13 15:43:36',

Re: [HACKERS] Bug in to_timestamp().

On 20.06.2016 16:36, Tom Lane wrote: Robert Haas writes: On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: 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

Re: [HACKERS] Bug in to_timestamp().

Tom Lane wrote: > I don't necessarily have an opinion yet. I would like to see more than > just an unsupported assertion about what Oracle's behavior is. Also, > how should FM mode affect this? I can supply what Oracle 12.1 does: SQL> SELECT to_timestamp('2016-06-13 15:43:36', ' /MM/DD

Re: [HACKERS] Bug in to_timestamp().

Robert Haas writes: > On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: >> 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

Re: [HACKERS] Bug in to_timestamp().

On Mon, Jun 20, 2016 at 8:19 AM, Robert Haas wrote: > On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas > wrote: > > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote: > >> amul sul writes: > >>> It's look like

Re: [HACKERS] Bug in to_timestamp().

On Mon, Jun 13, 2016 at 12:25 PM, Robert Haas wrote: > On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote: >> amul sul writes: >>> It's look like bug in to_timestamp() function when format string has more >>> whitespaces compare to

Re: [HACKERS] Bug in to_timestamp().

On Monday, 13 June 2016 9:57 PM, Robert Haas wrote: >I think a space in the format string should skip a whitespace >character in the input string, but not a non-whitespace character. +1, enough the benefit is we are giving correct output. PFA patch proposing this fix.

Re: [HACKERS] Bug in to_timestamp().

On Mon, Jun 13, 2016 at 12:12 PM, Tom Lane wrote: > amul sul 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

Re: [HACKERS] Bug in to_timestamp().

amul sul 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