| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
and ResultSet
|
|
|
|
parts o f postgresql. The jdbc drivers are never compiled with debugging
support. This p atch make sure that debugging information is added to
the jdbc jar when the --en able-debug is added. This was usefull for me
for debugging some java jdbc poolin g objects but this might perhaps be
usefull for other people too?
Dries Verachtert
|
|
|
|
The errors_zh_TW.properties must be translated using native2ascii or it
will raise an exception. Please replace the old file.
|
|
An attached patch corrects problem of this bug and fractional second.
The handling of time zone was as follows:
(a) with time zone
using SimpleDateFormat("yyyy-MM-dd HH:mm:ss z")
(b) without time zone
using SimpleDateFormat("yyyy-MM-dd HH:mm:ss")
About problem of fractional second,
Fractional second was changed from milli-second to nano-second
|
|
|
|
|
|
|
|
|
|
|
|
getColumnClassName(int) is not implemented. This will futher fixes method
ResultSet.getObject(int) since it requires the getColumnClassName(int) method to return the proper java class used to map the database column.
auther Ed Yu
|
|
fixes getIndexInfo throwing NullPointerException
fixes getIndexInfo improper results when multiple key indexs are used
|
|
fixes getIndexInfo throwing NullPointerException
fixes getIndexInfo improper results when multiple key indexs are used
|
|
|
|
Previous versions did not correctly identify primary/foreign keys
|
|
a problem with leading zeros being lost on fractional seconds when setting a timestamp value on a PreparedStatement.
|
|
driver was not properly handling timestamptz datatype when using the
getObject() method on ResultSet. Fix adds this datatype to the object mappings.
|
|
a get on a bytea value the code was running the raw value from the server
through character set conversion, which if the character set was SQL_ASCII
would cause all 8bit characters to become ?'s.
|
|
wasn't updated to handle more than two decimal digits for fractional seconds
that now are possible in 7.2. This patch fixes the timestamp parsing logic.
I have built and tested on both jdbc1 and jdbc2.
|
|
to be used, causing extra sql statements to be executed. This was a
significant performance problem with the database meta data classes.
The fix is a simple one liner.
|
|
The bug was that any insert or update would fail if the returned oid was
larger than a signed int. Since OIDs are unsigned int's it was
a bug that the code used a java signed int to deal with the values. The bug
would result in the error message: "Unable to fathom update count".
While fixing the bug, it became apparent that other code made a similar
assumption about OIDs being signed ints. Therefore some methods that returned
or took OIDs are arguements also needed to be changed.
Since we are so close to the 7.2 release I have added new methods that
return longs and deprecated the old methods returning ints. Therefore all
old code should still work without requiring a code change to cast from long to int. Also note that the methods below are PostgreSQL specific extensions to
the JDBC api are are not part of the spec from Sun, thus it is unlikely that
they are used much or at all.
The deprecated methods are:
ResultSet.getInsertedOID()
Statement.getInsertedOID()
Serialize.store()
Connection.putObject()
and are replaced by:
ResultSet.getLastOID()
Statement.getLastOID()
Serialize.storeObject()
Connection.storeObject()
All the deprecated methods returned int, while their replacements return long
This patch also fixes two comments in MD5Digest that the author Jeremy Wohl
submitted.
--Barry
|
|
|
|
|
|
|
|
|
|
|
|
absolute() problem.
There's also a little fix for the getRow() method. While fixing
absolute(), I noticed that getRow() wasn't quite following the spec: it
wasn't returning 0 when the ResultSet wasn't positioned on a row. I've
started a ResultSet test case and included it as well.
Liam Stewart
|
|
and 1.25). This checkin add back those two previous fixes. Problem reported by Daniel Germain
|
|
submitted by Jeremy Wohl jeremyw-pgjdbc@igmus.org
|
|
|
|
|
|
fixes for compiling Jason's getImportedKeys, getExportedKeys
|
|
|
|
|
|
|
|
|
|
Zhenbang Wei
|
|
reverts back unintentional change in behavior to return raw value even when not bytea column
|
|
VARHDRSZ first then and with 0xffff
|
|
applies same fix to jdbc1 code
|
|
|
|
from Mark Lillywhite. I am adding to the patch queue.
|
|
by tom_falconer@lineone.net. On Sept 7th, he sent a test case to the list demonstrating the bug. His test case now works successfully with this patch
|
|
|
|
|
|
That patch broke the ability to read data from binary cursors.
--Barry Lind
Modified Files:
pgsql/src/interfaces/jdbc/org/postgresql/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/core/QueryExecutor.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc1/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/Connection.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/ResultSet.java
pgsql/src/interfaces/jdbc/org/postgresql/jdbc2/UpdateableResultSet.java
|
|
select 'id' as xxx from table
The issue is:
When the driver gets a data type which does not map into the SQL.Types
it attempts to load the object into a java object. Eventually throwing
an exception indicating that the type "unknown" was not found.
Since the backend defaults "unknown" types to text it was suggested that
the jdbc driver do the same.
This patch does just that.
I have tested it on the above select statement as well as a small
program that serializes, and deserializes a class
Dave Cramer
|
