Bug 149552 – ResultSet.getInt alters numbers >= 2^24

Bug 149552 - ResultSet.getInt alters numbers >= 2^24

Summary:	ResultSet.getInt alters numbers >= 2^24

Status:	CLOSED ERRATA

Aliases:	None

Product:	Red Hat Enterprise Linux 3
Classification:	Red Hat
Component:	postgresql (Show other bugs)
Sub Component:
Version:	3.0
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Tom Lane
QA Contact:	David Lawrence
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2005-02-23 17:23 EST by Nathan Bronson
Modified:	2013-07-02 23:03 EDT (History)
CC List:	1 user (show)

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2005-02-23 20:19:30 EST
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Nathan Bronson 2005-02-23 17:23:40 EST

Description of problem:

  ResultSet.getInt loses precision for values larger than 2^24.

Version-Release number of selected component (if applicable):

  7.3.4-9

How reproducible:

  Every time.

Steps to Reproduce:

  Use the JDBC driver to select an int4 column containing the value
  16777217, retrieve it with ResultSet.getInt(1), and observe that
  the returned value is 16777216.
  
Actual results:

  Returned int is 16777216.

Expected results:

  Returned int is 16777217.

Additional info:

  org.postgresql.jdbc1.AbstractJdbc1ResultSet.toInt(String) parses
  string values by converting to a Float and then rounding to an
  int.  Float cannot exactly represent 16777217 (and many other
  useful values of int4).  A similar bug exists in the toLong method
  for large values of long.  Appears to be fixed in 7.3.9 and 7.4.6,
  but it should be documented somewhere that the 7.3.4 driver is
  fundamentally flawed.

Comment 1 Tom Lane 2005-02-23 18:24:44 EST

Since we're already shipping 7.3.9 as a security erratum for RHEL3,
shouldn't I just close this report as RESOLVED ERRATA?  AFAIK there
isn't any place to document historical bugs.  Or were you just
interested in creating a bugzilla entry for it?

Comment 2 Nathan Bronson 2005-02-23 20:06:56 EST

Yes, I was just trying to create a bugzilla entry, as it would have
saved me a day of work.  There may be others out there who haven't
upgraded to the latest version yet or who are trying to balance the
risk of an upgrade against the risk of not applying the errata.

Comment 3 Tom Lane 2005-02-23 20:19:30 EST

Fair enough, though we seldom try to make bugzilla entries for every
single upstream patch included in an update ...

Note You need to log in before you can comment on or make changes to this bug.