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

Re: [PATCHES] patch for ResultSet.java

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Alexander Litvinov <lan(at)ac-sw(dot)com>
Cc: Barry Lind <barry(at)xythos(dot)com>, pgsql-patches(at)postgresql(dot)org,pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [PATCHES] patch for ResultSet.java
Date: 2002-04-23 18:35:54
Message-ID: 200204231835.g3NIZsO25406@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-jdbcpgsql-patches
Alexander, can you verify that your problem is fixed in the current CVS
driver.  Thanks.

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

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
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2002-04-23 18:36:27
Subject: Re: doc patch for ALTER TRIGGER
Previous:From: Bruce MomjianDate: 2002-04-23 18:07:19
Subject: Re: RENAME TRIGGER patch (was [HACKERS] Odd(?) RI-trigger

pgsql-jdbc by date

Next:From: Ryan ChambersDate: 2002-04-23 20:23:17
Subject: JDBC and transactions
Previous:From: Tim PizeyDate: 2002-04-23 17:31:13
Subject: Re: help

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