Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] patch for ResultSet.java

From: Barry Lind <barry(at)xythos(dot)com>
To: Alexander Litvinov <lan(at)ac-sw(dot)com>
Cc: pgsql-patches(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [PATCHES] patch for ResultSet.java
Date: 2002-04-23 16:03:32
Message-ID: 3CC585D4.7090104@xythos.com (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-patches
Alexander,

Thanks for the additional information.  However upon researching this 
problem more, I find that it has already been fixed in current CVS.

thanks,
--Barry

Alexander Litvinov wrote:
> ec=> select version();
>                             version
> ---------------------------------------------------------------
>  PostgreSQL 7.1.3 on i686-pc-linux-gnu, compiled by GCC 2.95.3
> (1 row)
> 
> ec=> \d ab_contacts
>                                         Table "ab_contacts"
>    Attribute    |           Type           |                        Modifier
> ----------------+--------------------------+--------------------------------------------------------
>  id             | integer                  | not null default 
> nextval('"ab_contacts_id_seq"'::text)
> ....
>  marital_date   | timestamp with time zone |
> ...
> ec=> select marital_date from ab_contacts where id=752437;
>       marital_date
> ------------------------
>  0002-11-21 11:00:00.12
> (1 row)
> 
> ec=> update ab_contacts set marital_date='2002-1-1 10:10:10.12345' where 
> id=752437;
> UPDATE 1
> ec=> select marital_date from ab_contacts where id=752437;
>        marital_date
> ---------------------------
>  2002-01-01 10:10:10.12+06
> (1 row)
> but...
> ec=> update ab_contacts set marital_date='0002-1-1 10:10:10.12345' where 
> id=752437;
> UPDATE 1
> ec=> select marital_date from ab_contacts where id=752437;
>       marital_date
> ------------------------
>  0002-01-01 10:10:10.12
> (1 row)
> 
> 
> 
> 
> On Friday 19 April 2002 23:43, you wrote:
> 
>>Alexander,
>>
>>Can you describe the problem you are having a little better.  I don't
>>understand why you are getting "1903-12-29 18:00:12.68", you should be
>>getting something like "1903-12-29 18:00:12.68+05"  (i.e. the timezone
>>offset should be returned by the server.  What is the datatype of the
>>column you are selecting from?
>>
>>I need to better understand the cause of the problem so I can understand
>>the correctness of your patch.
>>
>>thanks,
>>--Barry
>>
>>Alexander Litvinov wrote:
>>
>>>If I try to fetch timestamp using rs,getTimestamp("name") I got:
>>>
>>>java.lang.StringIndexOutOfBoundsException: String index out of range: 22
>>>        at java.lang.String.charAt(String.java(Compiled Code))
>>>        at
>>>org.postgresql.jdbc2.ResultSet.toTimestamp(ResultSet.java:1653) at
>>>org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:398) at
>>>org.postgresql.jdbc2.ResultSet.getTimestamp(ResultSet.java:617)
>>>
>>>Later I tried to do rs.getString("name") I got: "1903-12-29 18:00:12.68"
>>>
>>>Using PostgreSQL v7.1.3 (JDBC from 7.2.1)
>>>
>>>I have added some bounds check to ResultSet.java. See attached patch.
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>--- src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java.original	Thu
>>>Apr 18 22:48:40 2002 +++
>>>src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java	Thu Apr 18
>>>22:57:44 2002 @@ -1641,17 +1641,22 @@
>>> 				int i = 19;
>>> 				resultSet.sbuf.setLength(i);
>>>
>>>-				char c = s.charAt(i++);
>>>+				char c = s.charAt(i);
>>> 				if (c == '.')
>>> 				{
>>> 					// Found a fractional value. Append up to 3 digits including
>>> 					// the leading '.'
>>>-					do
>>>-					{
>>>-						if (i < 24)
>>>+					resultSet.sbuf.append(c);
>>>+					i++;
>>>+					while (i < s.length() && i < 24) {
>>>+						c = s.charAt(i);
>>>+						if (Character.isDigit(c)) {
>>> 							resultSet.sbuf.append(c);
>>>-						c = s.charAt(i++);
>>>-					} while (Character.isDigit(c));
>>>+							i++;
>>>+						}
>>>+						else
>>>+						    break;
>>>+					}
>>>
>>> 					// If there wasn't at least 3 digits we should add some zeros
>>> 					// to make up the 3 digits we tell java to expect.
>>>@@ -1667,7 +1672,7 @@
>>> 				// prepend the GMT part and then add the remaining bit of
>>> 				// the string.
>>> 				resultSet.sbuf.append(" GMT");
>>>-				resultSet.sbuf.append(c);
>>>+//				resultSet.sbuf.append(c);
>>> 				resultSet.sbuf.append(s.substring(i, s.length()));
>>>
>>> 				// Lastly, if the tz part doesn't specify the :MM part then
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>---------------------------(end of broadcast)---------------------------
>>>TIP 3: if posting/reading through Usenet, please send an appropriate
>>>subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
>>>message can get through to the mailing list cleanly
>>
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html
> 



In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-04-23 16:19:21
Subject: Re: [HACKERS] WITH DELIMITERS in COPY
Previous:From: Christopher Kings-LynneDate: 2002-04-22 02:03:43
Subject: Re: [PATCHES] patch for ResultSet.java

pgsql-jdbc by date

Next:From: Nick FankhauserDate: 2002-04-23 16:19:08
Subject: Re: help
Previous:From: Dave CramerDate: 2002-04-23 12:59:16
Subject: Re: throw SQLException on no rs.next()?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group