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

Re: BUG #5099: When MetaData is acquired, it becomes an SQL error.

From: Kris Jurka <books(at)ejurka(dot)com>
To: konishi <a(dot)konisi(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org, z-saito(at)guitar(dot)ocn(dot)ne(dot)jp
Subject: Re: BUG #5099: When MetaData is acquired, it becomes an SQL error.
Date: 2009-12-07 22:50:56
Message-ID: alpine.BSO.2.00.0912071745420.18090@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-bugs

On Wed, 7 Oct 2009, konishi wrote:

> Bug reference:      5099
> PostgreSQL version: 8.4.1
> Description:        When MetaData is acquired, it becomes an SQL error.
> Details:
>
> In sample source and sample db
> when used postgresql-8.4-701.jdbc3.jar is error
> when used postgresql-8.3-603.jdbc3.jar is no error
>
>
> The error disappears when "prepared.getParameterMetaData()" row delete.
>
> String url = "jdbc:postgresql://XXX.XXX.XXX.XXX:5432/test";
> Connection con = DriverManager.getConnection(url, "postgres", "test");
> try{
>    String sql = "insert into test(filename,upddate) values(?,?)";
>    PreparedStatement prepared = con.prepareStatement(sql);
>    System.out.println("ParameterMetaData[" +
> prepared.getParameterMetaData() + "]");
>    prepared.setString(1, "0");
>    prepared.setTimestamp(2, new
> Timestamp(Calendar.getInstance().getTimeInMillis()));
>    prepared.executeUpdate();
> }catch(Exception e){
>    System.out.println(e.getMessage());
> }
>
> error message:
> java.lang.IllegalArgumentException: Can't change resolved type for param: 1
> from 1043 to 25
> 	at
> org.postgresql.core.v3.SimpleParameterList.setResolvedType(SimpleParameterLi
> st.java:230)
> 	at


I have applied a fix to CVS for this problem and it will be included in 
the next release.

For the 8.4 release an optimization was added to avoid re-describing a 
statement if we already had the type information available by copying the 
resolved type information from the query to the provided parameters.  Its 
goal was just to overwrite parameters without a type (unknown), but it was 
actually overwriting all types which could change the query's desired 
behavior.  In this case a safeguard to prevent that change was throwing 
the exception noted.

Kris Jurka

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-12-08 00:09:08
Subject: Re: BUG #5235: Segmentation fault under high load through JDBC
Previous:From: Oleg YurchenkoDate: 2009-12-07 21:43:31
Subject: BUG #5235: Segmentation fault under high load through JDBC

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