dbTalk Databases Forums  

Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in

mailing.database.pgsql-bugs mailing.database.pgsql-bugs


Discuss Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in in the mailing.database.pgsql-bugs forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in - 09-02-2006 , 08:24 PM







--ELM1157246513-22585-1_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

Josh Tolley wrote:
Quote:
The following bug has been logged online:

Bug reference: 2599
Logged by: Josh Tolley
Email address: eggyknap (AT) gmail (DOT) com
PostgreSQL version: 8.1.4
Operating system: Fedora Core 5
Description: AM/PM doesn't work in to_timestamp in the middle of a
string
Details:

eggyknap=# select to_timestamp('30 Aug 06:01:03.223 PM 2006', 'DD Mon
HH:MI:SS.MS AM YYYY'), to_timestamp('30 Aug 2006 06:01:03.223 PM', 'DD Mon
YYYY HH:MI:SS.MS AM');
to_timestamp | to_timestamp
---------------------------+----------------------------
0001-08-30 18:01:03-08 BC | 2006-08-30 18:01:03.223-06

This appears to happen when AM/PM isn't the last element in the string.
Nice report. The attached patch fixes it, and will be in 8.2. I am not
backpatching because someone might be relying on this behavior.

--
Bruce Momjian bruce (AT) momjian (DOT) us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--ELM1157246513-22585-1_
Content-Transfer-Encoding: 7bit
Content-Type: text/x-diff
Content-Disposition: inline; filename="/bjm/diff"

Index: src/backend/tcop/pquery.c
================================================== =================
RCS file: /cvsroot/pgsql/src/backend/tcop/pquery.c,v
retrieving revision 1.108
diff -c -c -r1.108 pquery.c
*** src/backend/tcop/pquery.c 2 Sep 2006 18:17:17 -0000 1.108
--- src/backend/tcop/pquery.c 3 Sep 2006 01:13:20 -0000
***************
*** 1347,1353 ****
* we are. In any case, we arrange to fetch the target row
* going forwards.
*/
! if (portal->posOverflow || portal->portalPos == LLONG_MAX ||
count - 1 <= portal->portalPos / 2)
{
DoPortalRewind(portal);
--- 1347,1353 ----
* we are. In any case, we arrange to fetch the target row
* going forwards.
*/
! if (portal->posOverflow || portal->portalPos == FETCH_ALL ||
count - 1 <= portal->portalPos / 2)
{
DoPortalRewind(portal);
Index: src/include/nodes/parsenodes.h
================================================== =================
RCS file: /cvsroot/pgsql/src/include/nodes/parsenodes.h,v
retrieving revision 1.327
diff -c -c -r1.327 parsenodes.h
*** src/include/nodes/parsenodes.h 2 Sep 2006 18:17:17 -0000 1.327
--- src/include/nodes/parsenodes.h 3 Sep 2006 01:13:22 -0000
***************
*** 14,19 ****
--- 14,21 ----
#ifndef PARSENODES_H
#define PARSENODES_H

+ #include "limits.h"
+
#include "nodes/primnodes.h"
#include "nodes/value.h"

***************
*** 1439,1445 ****
--- 1441,1452 ----
FETCH_RELATIVE
} FetchDirection;

+ #ifdef HAVE_INT64
#define FETCH_ALL LLONG_MAX
+ #else
+ #define FETCH_ALL LONG_MAX
+ #endif
+

typedef struct FetchStmt
{

--ELM1157246513-22585-1_
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

--ELM1157246513-22585-1_--


Reply With Quote
  #2  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in - 09-02-2006 , 10:50 PM







--ELM1157255238-9436-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"

bruce wrote:
Quote:
Josh Tolley wrote:

The following bug has been logged online:

Bug reference: 2599
Logged by: Josh Tolley
Email address: eggyknap (AT) gmail (DOT) com
PostgreSQL version: 8.1.4
Operating system: Fedora Core 5
Description: AM/PM doesn't work in to_timestamp in the middle of a
string
Details:

eggyknap=# select to_timestamp('30 Aug 06:01:03.223 PM 2006', 'DD Mon
HH:MI:SS.MS AM YYYY'), to_timestamp('30 Aug 2006 06:01:03.223 PM', 'DD Mon
YYYY HH:MI:SS.MS AM');
to_timestamp | to_timestamp
---------------------------+----------------------------
0001-08-30 18:01:03-08 BC | 2006-08-30 18:01:03.223-06

This appears to happen when AM/PM isn't the last element in the string.

Nice report. The attached patch fixes it, and will be in 8.2. I am not
backpatching because someone might be relying on this behavior.
Sorry, I attached the wrong patch to the email. This is the right one.

--
Bruce Momjian bruce (AT) momjian (DOT) us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

--ELM1157255238-9436-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/x-diff
Content-Disposition: inline; filename="/bjm/diff"

Index: src/backend/utils/adt/formatting.c
================================================== =================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/formatting.c,v
retrieving revision 1.110
retrieving revision 1.111
diff -c -r1.110 -r1.111
*** src/backend/utils/adt/formatting.c 19 Apr 2006 18:49:09 -0000 1.110
--- src/backend/utils/adt/formatting.c 3 Sep 2006 01:22:56 -0000 1.111
***************
*** 1762,1768 ****
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(p_inout);
}
break;
case DCH_AM:
--- 1762,1768 ----
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(P_M_STR);
}
break;
case DCH_AM:
***************
*** 1781,1787 ****
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(p_inout);
}
break;
case DCH_a_m:
--- 1781,1787 ----
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(PM_STR);
}
break;
case DCH_a_m:
***************
*** 1800,1806 ****
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(p_inout);
}
break;
case DCH_am:
--- 1800,1806 ----
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(p_m_STR);
}
break;
case DCH_am:
***************
*** 1819,1825 ****
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(p_inout);
}
break;
case DCH_HH:
--- 1819,1825 ----
tmfc->am = TRUE;
else
AMPM_ERROR;
! return strlen(pm_STR);
}
break;
case DCH_HH:

--ELM1157255238-9436-0_
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

--ELM1157255238-9436-0_--


Reply With Quote
  #3  
Old   
Andrew - Supernews
 
Posts: n/a

Default Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in - 09-04-2006 , 03:13 AM



On 2006-09-03, Bruce Momjian <bruce (AT) momjian (DOT) us> wrote:
Quote:
Nice report. The attached patch fixes it, and will be in 8.2. I am not
backpatching because someone might be relying on this behavior.
The bug appears to have been introduced just before the 8.1 betas; since
it causes the AM/PM indicator simply to never work except at the end of
the string, I see no possible justification for not backpatching the fix.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq


Reply With Quote
  #4  
Old   
Bruce Momjian
 
Posts: n/a

Default Re: [BUGS] BUG #2599: AM/PM doesn't work in to_timestamp in - 09-04-2006 , 02:32 PM




Backpatched to 8.1.X.

---------------------------------------------------------------------------

Andrew - Supernews wrote:
Quote:
On 2006-09-03, Bruce Momjian <bruce (AT) momjian (DOT) us> wrote:
Nice report. The attached patch fixes it, and will be in 8.2. I am not
backpatching because someone might be relying on this behavior.

The bug appears to have been introduced just before the 8.1 betas; since
it causes the AM/PM indicator simply to never work except at the end of
the string, I see no possible justification for not backpatching the fix.

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq
--
Bruce Momjian bruce (AT) momjian (DOT) us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.