From: | "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp> |
---|---|
To: | "Kris Jurka" <books(at)ejurka(dot)com>, "konishi" <a(dot)konisi(at)gmail(dot)com> |
Cc: | <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #5099: When MetaData is acquired, it becomes an SQL error. |
Date: | 2009-12-08 14:27:18 |
Message-ID: | 8D811910793F4B499C076F03B36B80C5@acer08f817a9b5 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Hi Kris-san.
Great, thanks!!
You have spent very much time for this problem.
I think very many Postgres users was helped by it.
Thanks again:-)
Regards,
Hiroshi Saito
----- Original Message -----
From: "Kris Jurka" <books(at)ejurka(dot)com>
>
>
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Jurtšenko | 2009-12-08 18:33:28 | Re: BUG #5235: Segmentation fault under high load through JDBC |
Previous Message | Craig Ringer | 2009-12-08 12:19:34 | Re: BUG #5235: Segmentation fault under high load through JDBC |