Thread: patch: ResultSetTest.java
Here are a couple of problems I ran across in ResultSetTest.
The first section removes an assertion that is redundant and makes the (not necessarily true) assumption that the field
wasreturned by the database in text format. From the Javadoc on java.sql.ResultSet.getBytes(): "The bytes represent
theraw values returned by the driver."
The second section has an unnecessarily complex query that caused me problems because pg_database contains a column of
typeaclitem[] which does not support binary transfer from the database.
Ken
===================================================================
RCS file: /usr/local/cvsroot/pgjdbc/pgjdbc/org/postgresql/test/jdbc2/ResultSetTest.java,v
retrieving revision 1.25
diff -u -r1.25 ResultSetTest.java
--- jdbc2/ResultSetTest.java 11 Jan 2005 08:25:48 -0000 1.25
+++ jdbc2/ResultSetTest.java 25 Oct 2005 08:09:13 -0000
@@ -170,14 +170,12 @@
//it should apply only to binary and char/varchar columns
rs.next();
assertEquals("12345", rs.getString(1));
- assertEquals("12345", new String(rs.getBytes(1)));
//max should apply to the following since the column is
//a varchar column
rs = stmt.executeQuery("select * from teststring");
rs.next();
assertEquals("12", rs.getString(1));
- assertEquals("12", new String(rs.getBytes(1)));
}
public void booleanTests(boolean useServerPrepare) throws SQLException
@@ -485,7 +483,7 @@
{
Statement stmt = con.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);
// Create a one row result set.
- ResultSet rs = stmt.executeQuery("SELECT * FROM pg_database WHERE datname='template1'");
+ ResultSet rs = stmt.executeQuery("SELECT 1");
assertTrue(rs.isBeforeFirst());
assertTrue(!rs.isAfterLast());
kgeis@speakeasy.net wrote: > Here are a couple of problems I ran across in ResultSetTest. Uh, what are the failures you see? -O
kgeis@speakeasy.net writes:
> The second section has an unnecessarily complex query that caused me
> problems because pg_database contains a column of type aclitem[] which
> does not support binary transfer from the database.
Say what?
The proposed change is probably a good idea anyway, primarily because
there isn't necessarily any template1 database. But if fetching
aclitem[] fails then there's something quite wrong, and I don't believe
it's on the server side.
regards, tom lane
On Oct 25, 2005, at 6:32 AM, Tom Lane wrote: > kgeis@speakeasy.net writes: >> The second section has an unnecessarily complex query that caused me >> problems because pg_database contains a column of type aclitem[] which >> does not support binary transfer from the database. > > Say what? > > The proposed change is probably a good idea anyway, primarily because > there isn't necessarily any template1 database. But if fetching > aclitem[] fails then there's something quite wrong, and I don't believe > it's on the server side. > > regards, tom lane aclitem is one of few types that does not have send and receive functions defined. According to the docs for "CREATE TYPE," "If this function is not supplied, the type cannot participate in binary output." The problem came up for me because I am implementing binary data transfer in the JDBC driver, and my first draft assumes that all data transfers are binary. I worked around it elsewhere by converting it to a string within SQL (curiously, I couldn't cast it to text, but I could call array_to_string on an aclitem[]). Ken
Ken Geis <kgeis@speakeasy.net> writes:
> On Oct 25, 2005, at 6:32 AM, Tom Lane wrote:
>> The proposed change is probably a good idea anyway, primarily because
>> there isn't necessarily any template1 database. But if fetching
>> aclitem[] fails then there's something quite wrong, and I don't believe
>> it's on the server side.
> aclitem is one of few types that does not have send and receive
> functions defined.
Oh, my mistake, I looked at the entry for _aclitem ... but you're right,
the underlying type doesn't have 'em.
> The problem came up for me because I am implementing binary
> data transfer in the JDBC driver, and my first draft assumes that all
> data transfers are binary.
This is a really bad assumption, unless you intend never to support any
user-defined types.
regards, tom lane
> Oliver Jowett write:
> kgeis@speakeasy.net wrote:
> > Here are a couple of problems I ran across in ResultSetTest.
>
> Uh, what are the failures you see?
Uh, doesn't it matter that the tests are wrong? :)
It may help to explain that these issues are coming up as I implement binary data transfer in the JDBC driver. It's
beentwo years since it's been available as a feature in the database and I couldn't wait for the feature to show up in
theJDBC driver. The team may not like my implementation, but the world needs to know what it's missing (I got 100%
speedupin a silly little benchmark.)
Anyway, here are the failures:
[junit] Testcase: testMaxFieldSize(org.postgresql.test.jdbc2.ResultSetTest):
FAILED
[junit] expected:<12345> but was:< 09>
[junit] junit.framework.ComparisonFailure: expected:<12345> but was:< 09>
[junit] Testcase: testRowResultPositioning(org.postgresql.test.jdbc2.ResultS
etTest): Caused an ERROR
[junit] ERROR: no binary output function available for type aclitem
[junit] Location: File: arrayfuncs.c, Routine: array_send, Line: 1384
[junit] Server SQLState: 42883
On Oct 25, 2005, at 8:00 AM, Tom Lane wrote: > Ken Geis <kgeis@speakeasy.net> writes: >> The problem came up for me because I am implementing binary >> data transfer in the JDBC driver, and my first draft assumes that all >> data transfers are binary. > > This is a really bad assumption, unless you intend never to support any > user-defined types. Yes, I know. That's why I said "first draft." My goal is to hack together a driver that works in most cases and gets the community to realize that binary data transfer is great and the JDBC driver needs some active development. Ken
kgeis@speakeasy.net wrote: >>Oliver Jowett write: >>kgeis@speakeasy.net wrote: >> >>>Here are a couple of problems I ran across in ResultSetTest. >> >>Uh, what are the failures you see? > > > Uh, doesn't it matter that the tests are wrong? :) The tests are fine for the current driver, right? > It may help to explain that these issues are coming up as I implement binary data transfer in the JDBC driver. I'd suggest you submit the test changes as part of that patch. -O
Tom Lane wrote: > Ken Geis <kgeis@speakeasy.net> writes: >>aclitem is one of few types that does not have send and receive >>functions defined. > > Oh, my mistake, I looked at the entry for _aclitem ... but you're right, > the underlying type doesn't have 'em. Hm, this would seem to be an obstacle to using binary output formats in a general-purpose client.. The driver generally does not know the type of the columns returned by a query ahead of time (without an extra round-trip, which has a performance cost), so returning columns as binary is going to be all-or-nothing. If the act of selecting binary output for a column is going to cause an ERROR on a query that would otherwise succeed.. that's pretty nasty :( Any plans for the backend to require send/receive functions for all types? Or perhaps something like using the input/output functions if send/receive are not present? -O
Oliver Jowett <oliver@opencloud.com> writes:
> Any plans for the backend to require send/receive functions for all
> types?
Highly unlikely, since that would break most user-defined types in existence.
> Or perhaps something like using the input/output functions if
> send/receive are not present?
Doesn't seem like an amazingly good idea ... how would you know what you
were getting?
A more salient point is exactly what is JDBC going to *do* with data in
an unknown binary format?
You may have to fall back to providing a switch somewhere that says
whether or not to use binary I/O, with the understanding that it's only
safe to turn it on when all the queries use only supported types.
regards, tom lane
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: > >>Or perhaps something like using the input/output functions if >>send/receive are not present? > > Doesn't seem like an amazingly good idea ... how would you know what you > were getting? Err, the same question applies to any binary data type, surely. You have to know what format the data is in to make use of it. The issue is that getting an ERROR in this case makes the binary output formats somewhat useless.. I was thinking of it as "if you do not specify send/receive functions, then the 'binary' format is the same as the text format". Is that unreasonable to do? > A more salient point is exactly what is JDBC going to *do* with data in > an unknown binary format? Well, my plan back when I looked at this last was to just store the binary-format data on the client side, and if the application actually asked for it in text format (directly or implicitly), send it back to the backend as a binary-format parameter to a SELECT that returns a text-format column (i.e. ask the backend to do the work of turning it into text, since the driver doesn't know how to). That would work fine except for this ERROR case. -O