Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Result of AbstractJdbc2ResultSet.getBigDecimal(int) is shifted by order of magnitude #424

Closed
azuritus opened this issue Nov 13, 2015 · 1 comment

Comments

@azuritus
Copy link

@azuritus azuritus commented Nov 13, 2015

When using the latest 9.4-1205-jdbc42 JDBC driver with a bigint column, getBigDecimal(int) returns value shifted by order of magnitude - multiplied by 10.

It looks like this is caused by performace optimization introduced in 33904ef.

In this case getBigDecimal(int columnIndex, int scale) gets called from getBigDecimal(int columnIndex) with scale = -1. Why -1 is passed instead of 0 is not yet clear to me.

Reason why this used to work before is that invalid scale is not passed into getFastBigDecimal(int columnIndex) and instead scale is correctly calculated as zero.

@polobo
Copy link

@polobo polobo commented Nov 13, 2015

Yeah, its not clear why "-1" is special-cased in "toBigDecimal" but because
it is the new BigDecimal call needs to repeat that logic because it
bypasses that call.

David J.

On Fri, Nov 13, 2015 at 8:25 AM, Pavel Hrabec notifications@github.com
wrote:

When using the latest 9.4-1205-jdbc42 JDBC driver with a bigint column,
getBigDecimal(int) returns value shifted by order of magnitude -
multiplied by 10.

It looks like this is caused by performace optimization introduced in
33904ef
33904ef
.

In this case getBigDecimal(int columnIndex, int scale) gets called from getBigDecimal(int
columnIndex) with scale = -1. Why -1 is passed instead of 0 is not yet
clear to me.

Reason why this used to work before is that invalid scale is not passed
into getFastBigDecimal(int columnIndex) and instead scale is correctly
calculated as zero.


Reply to this email directly or view it on GitHub
#424.

vlsi added a commit to Gordiychuk/pgjdbc that referenced this issue Nov 13, 2015
…imal()

It turns out BigDecimal.valueOf(12, 1) == "12.1" while BigDecimal.valueOf(12).setScale(1) == "12.0"
Added new property to configure rounding mode for setScale: roundingMode that defaults to HALF_EVEN

fixes pgjdbc#424
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants