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
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
DatabaseMetaData.getColumn(). I proposed a patch that would change the
number of queries to find out all columns in a table from 2 * N + 1 to 1 (N
being the number of columns reported) by using some outer joins. I also
fixed the fact that getColumns() only returned columns that had a default
defined. OTOH, I did not use to change the code required for obtaining a
column's remarks (by using col_description() for 7.2 and requested by Tom
Lane).
Finally, I have found a way to get all the column details in a single query
*and* use col_description() for 7.2 servers. A patch is attached. It
overrules Ren? Pijlman's fix for this that was committed just today, but
still used N + 1 queries (sorry Ren? ;-) )
I also fixed the return values for TABLE_CAT and TABLE_SCHEM from "" to
null, to be more standard compliant (and requested in Ren?'s mail found at
http://fts.postgresql.org/db/mw/msg.html?mid=1034253).
As always, the JDBC1 version has not been tested as I have no JDK 1.1
Jeroen van Vianen
summary of changes:
. removal of the tablename property from build.xml
. addition of a dropTable method in JDBC2Tests and cleanups of many
methods in the same
. all tests now use non-deprecated assertXYZ methods instead of the
deprecated assert method
. failure in TimestampTest (testSetTimestamp) fixed. The failure is
because testSetTimestamp was inserting a timestamp with hour 7 but
checkTimeTest was expecting a timestamp with hour 8. AFAICS, there are
no issues wrt daylight savings time and timestamps being pushed in and
pulled out (but more explicit tests should be added in the future)
. failure in TimeTest (testGetTime) fixed. Times to be inserted were
interpreted in the localtime zone but checking was done with the
assumption that the insertion was done in GMT.
. formatting changes in a few of the source files (because I found
it convenient to have consistent formatting while working on them). The
formatting is consistent with the new format for java source files in
PostgreSQL.
Liam Stewart
the JDBC driver.
This method is currently unimplemented and always returns
ResultSetMetaData.columnNullable. This is obviously incorrect
when a column is defined with NOT NULL or PRIMARY KEY. And we
have to think of check constraints, views, functions etc.
The patch simply changes the return value to
ResultSetMetaData.columnNullableUnknown. This is until someone
comes up with a real implementation of course.
On Fri, 14 Sep 2001 17:53:50 +0200, Tomisaw Kity?ski wrote:
>Hello there,
>
>could someone tell me, please, do I have any chance to get
>proper implementation of above method in JDBC (1.1+) soon?
>
>Current "return 1" works fine on most tables, however it seems
>to be a little bit incorrect with some of them ;)
Ren? Pijlman
by escape processing in the SQL statement. I've tested this for a
while now and it appears to work well. Previously string data
with {d was getting corrupt as the {d was being stripped regardless
of whether it was an escape code or not.
I also added checking for time and timestamp escape processing strings
as per 11.3 in the specification. The patch is against the latest
CVS.
Thomas O'Dowd
> null bytes to be literally '\0', the following can happen:
> 1. User inputs string value as "<null byte>##" where ## are digits in the
> range of 0 to 7.
> 2. PQescapeString converts this to "\0##"
> 3. Escaped string is used in a context that causes "\0##" to be evaluated as
> an octal escape sequence.
I agree that this is a problem, though it is not possible to do
anything harmful with it. In addition, it only occurs if there are
any NUL characters in its input, which is very unlikely if you are
using C strings.
The patch below addresses the issue by removing escaping of \0
characters entirely.
> If the goal is to "safely" encode null bytes, and preserve the rest of the
> string as it was entered, I think the null bytes should be escaped as \\000
> (note that if you simply use \000 the same string truncation problem
> occurs).
We can't do that, this would require 4n + 1 bytes of storage for the
result, breaking the interface.
Florian Weimer
driver's test suite. With previous patches applied, this reduces
the number of failures of the test suite from 6 to 4. The patch
fixes the test case itself, rather than the driver.
Details:
1) The driver correctly provided DatabaseMetaData about the sort
order of NULLs. This was confirmed by Peter Eisentraut on
pgsql-hackers. I fixed the test to accept/require the current
behaviour, and made it dependent on the backend version. See
nullsAreSortedAtStart(), nullsAreSortedAtEnd(),
nullsAreSortedHigh() and nullsAreSortedLow().
2) DatabaseMetaData.supportsOrderByUnrelated() correctly
returned true (an ORDER BY clause can contain columns that are
not in the SELECT clause), but the test case required false.
Fixed that.
3) Replaced deprecated assert() of junit.framework.TestCase by
assertEquals(), assertTrue() and assertNotNull(). This is
because assert will be a new keyword in Java 1.4.
4) Replaced assert(message,false) by the more elegant
fail(message).
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
This patch does the following:
- Adds binary datatype support (bytea)
- Changes getXXXStream()/setXXXStream() methods to be spec compliant
- Adds ability to revert to old behavior
Details:
Adds support for the binary type bytea. The ResultSet.getBytes() and
PreparedStatement.setBytes() methods now work against columns of bytea
type. This is a change in behavior from the previous code which assumed
the column type was OID and thus a LargeObject. The new behavior is
more complient with the JDBC spec as BLOB/CLOB are to be used for
LargeObjects and the getBytes()/setBytes() methods are for the databases
binary datatype (which is bytea in postgres).
Changes the behavior of the getBinaryStream(), getAsciiStream(),
getCharacterStream(), getUnicodeStream() and their setXXXStream()
counterparts. These methos now work against either the bytea type
(BinaryStream) or the text types (AsciiStream, CharacterStream,
UnicodeStream). The previous behavior was that these all assumed the
underlying column was of type OID and thus a LargeObject. The
spec/javadoc for these methods indicate that they are for LONGVARCHAR
and LONGVARBINARY datatypes, which are distinct from the BLOB/CLOB
datatypes. Given that the bytea and text types support upto 1G, they
are the LONGVARBINARY and LONGVARCHAR datatypes in postgres.
Added support for turning off the above new functionality. Given that
the changes above are not backwardly compatible (however they are more
spec complient), I added the ability to revert back to the old behavior.
The Connection now takes an optional parameter named 'compatible'. If
the value of '7.1' is passed, the driver reverts to the 7.1 behavior.
If the parameter is not passed or the value '7.2' is passed the behavior
is the new behavior. The mechanism put in place can be used in the
future when/if similar needs arise to change behavior. This is
patterned after how Oracle does this (i.e. Oracle has a 'compatible'
parameter that behaves in a similar manner).
Misc fixes. Cleaned up a few things I encountered along the way.
Note that in testing the patch I needed to ignore whitespace differences
in order to get it to apply cleanly (i.e. patch -l -i byteapatch.diff).
Also this patch introduces a new file
(src/interfaces/jdbc/org/postgresql/util/PGbytea.java).
Barry Lind
>there is still an unpatched reference to pg_description in
>getColumns(), in both jdbc1 and jdbc2.
This was introduced by Jeroen's patch (see
http://fts.postgresql.org/db/mw/msg.html?mid=1032468). Attached
is a patch that returns getColumns() to using "select
obj_description()" instead of direct access to pg_description,
as per the request by Tom.
I've incorporated Jeroen's fix to left outer join with
pg_attrdef instead of inner join, so getColumns() also returns
columns without a default value.
I have, however, not included Jeroen's attempt to combine
multiple queries into one huge multi-join query for better
performance, because:
1) I don't know how to do that using obj_description() instead
of direct access to pg_description
2) I don't think a performance improvement (if any) in this
method is very important
Because of the outer join, getColumns() will only work with a
backend >= 7.1. Since the conditional coding for 7.1/7.2 and
jdbc1/jdbc2 is already giving me headaches I didn't pursue a
pre-7.1 solution.
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
ConnectionTest.testTransactionIsolation() in the JDBC driver's
test suite. This reduces the number of failures of the test
suite from 7 to 6. The patch fixes the test case itself, rather
than the driver.
In addition to the change described in my posting below, I fixed
the part of the test with autocommit enabled. The author of the
test assumed that setting the transaction isolation level would
have no effect, but in fact it does. Perhaps the test case
worked with pre-7.1 behaviour, when the JDBC driver set the
isolation level in every transaction, instead of using "set
session characteristics". Anyway, now it works with a backend
built from current CVS and the behaviour is JDBC compliant.
I also extended the test case by changing the isolation level
before beginning a transaction and verifying it inside the
transaction.
Regards,
Ren? Pijlman
suite. This reduces the number of failures from 9 to 7.
Both ConnectionTest and JBuilderTest did not create their own
tables, which caused these test cases to fail with "relation ...
does not exist". It appears these test cases relied on tables
created by the example code elsewhere in the source tree. I've
added the necessary "create table" and "drop table" statements
to the test cases, using the column definitions from the example
code.
While working on that I modified the helper method createTable
in JDBC2Tests.java to take a table parameter, rather than using
table names passed via the properties in build.xml. I'm not sure
what that was good for, and in fact, except for the default
table name "jdbctest", this functionality wasn't used at all.
Ren? Pijlman
>
>> On Mon, 3 Sep 2001 22:01:17 -0500, you wrote:
>> public boolean isWritable(int column) throws SQLException
>> {
>> return !isReadOnly(column);
>> }
Actually, I think this change has a consequence for this method
in the same class:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return isWritable(column);
}
This is from the JDBC spec
(http://java.sun.com/j2se/1.3/docs/api/java/sql/ResultSetMetaData.html):
isReadOnly() - Indicates whether the designated column is
definitely not writable.
isWritable() - Indicates whether it is possible for a write on
the designated column to succeed.
isDefinitelyWritable() - Indicates whether a write on the
designated column will definitely succeed.
At this time we don't really implement the fine semantics of
these methods. I would suggest the following defaults:
isReadOnly() false
isWritable() true
isDefinitelyWritable() false
And that would mean that your patch is correct, but
isDefinitelyWritable() would need to be patched accordingly:
public boolean isDefinitelyWritable(int column)
throws SQLException
{
return false;
}
Again, both in jdbc1 and jdbc2.
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
>public boolean isWritable(int column) throws SQLException
>{
> if (isReadOnly(column))
> return true;
> else
> return false;
>}
The author probably intended:
public boolean isWritable(int column) throws SQLException
{
return !isReadOnly(column);
}
And if he would have coded it this way he wouldn't have made
this mistake :-)
>hence, isWritable() will always return false. this is something
>of a problem :)
Why exactly? In a way, true is just as incorrect as false, and
perhaps it should throw "not implemented". But I guess that
would be too non-backwardly-compatible.
>let me know if i can provide further information.
Will you submit a patch?
Regards,
Ren? Pijlman <rene@lab.applinet.nl>
flawed in the following ways:
1. Only returned columns that had a default value defined, rather than all
columns in a table
2. Used 2 * N + 1 queries to find out attributes, comments and typenames
for N columns.
By using some outer join syntax it is possible to retrieve all necessary
information in just one SQL statement. This means this version is only
suitable for PostgreSQL >= 7.1. Don't know whether that's a problem.
I've tested this function with current sources and 7.1.3 and patched both
jdbc1 and jdbc2. I haven't compiled nor tested the jdbc1 version though, as
I have no JDK 1.1 available.
Note the discussion in http://fts.postgresql.org/db/mw/msg.html?mid=1029626
regarding differences in obtaining comments on database object in 7.1 and
7.2. I was unable to use the following syntax (or similar ones):
select
...,
description
from
...
left outer join col_description(a.attrelid, a.attnum) description
order by
c.relname, a.attnum;
(the error was parse error at or near '(') so I had to paste the actual
code for the col_description function into the left outer join. Maybe
someone who is more knowledgable about outer joins might provide me with a
better SQL statement.
Jeroen van Vianen
the JDBC driver.
I've done this by extracting it into a new method object called
QueryExecutor (should go into org/postgresql/core/) and then taking it
apart into different methods in that class.
A short summary:
* Extracted ExecSQL() from Connection into a method object called
QueryExecutor.
* Moved ReceiveFields() from Connection to QueryExecutor.
* Extracted parts of the original ExecSQL() method body into smaller
methods on QueryExecutor.
* Bug fix: The instance variable "pid" in Connection was used in two
places with different meaning. Both were probably in dead code, but it's
fixed anyway.
Anders Bengtsson
for the changed files and a few new files:
- test/jdbc2/BatchExecuteTest.java
- util/MessageTranslator.java
- jdbc2/PBatchUpdateException.java
As an aside, is this the best way to submit a patch consisting
of both changed and new files? Or is there a smarter cvs command
which gets them all in one patch file?
This patch fixes batch processing in the JDBC driver to be
JDBC-2 compliant. Specifically, the changes introduced by this
patch are:
1) Statement.executeBatch() no longer commits or rolls back a
transaction, as this is not prescribed by the JDBC spec. Its up
to the application to disable autocommit and to commit or
rollback the transaction. Where JDBC talks about "executing the
statements as a unit", it means executing the statements in one
round trip to the backend for better performance, it does not
mean executing the statements in a transaction.
2) Statement.executeBatch() now throws a BatchUpdateException()
as required by the JDBC spec. The significance of this is that
the receiver of the exception gets the updateCounts of the
commands that succeeded before the error occurred. In order for
the messages to be translatable, java.sql.BatchUpdateException
is extended by org.postgresql.jdbc2.PBatchUpdateException() and
the localization code is factored out from
org.postgresql.util.PSQLException to a separate singleton class
org.postgresql.util.MessageTranslator.
3) When there is no batch or there are 0 statements in the batch
when Statement.executeBatch() is called, do not throw an
SQLException, but silently do nothing and return an update count
array of length 0. The JDBC spec says "Throws an SQLException if
the driver does not support batch statements", which is clearly
not the case. See testExecuteEmptyBatch() in
BatchExecuteTest.java for an example. The message
postgresql.stat.batch.empty is removed from the language
specific properties files.
4) When Statement.executeBatch() is performed, reset the
statement's list of batch commands to empty. The JDBC spec isn't
100% clear about this. This behaviour is only documented in the
Java tutorial
(http://java.sun.com/docs/books/tutorial/jdbc/jdbc2dot0/batchupdates.html).
Note that the Oracle JDBC driver also resets the statement's
list in executeBatch(), and this seems the most reasonable
interpretation.
5) A new test case is added to the JDBC test suite which tests
various aspects of batch processing. See the new file
BatchExecuteTest.java.
Regards,
Ren? Pijlman
