Dave Cramer <pg(at)fastcrypt(dot)com> writes:
> Also it would be nice if a test case came with this patch.
I've written a testsuite for this patch. It tests the three cases of
length < 0, length > Integer.MAX_VALUE and that it actually works.
The testcase that tests if the feature is working properly uses the
prepared statement SELECT ?::TEXT and compares the returned hex value.
This is not a good idea because it depends on the bytea -> text
conversion which has changed in recent Postgres versions, right?
What is a good way to isolate the test code from version specific
behaviour? In this case, whether bytea to text is _escape_ or _hex_.
Now that we're using git, is there any point in CVS identification
strings in new files? Also, I only state Copyright 2012 for new files,
and not 20xx-2012, right?
When tests are catching SQL exceptions and comparing the error code, do
we want to hard code them, or refer to PSQLState constants? Personally,
I do not believe in using the same constants in test and production code.
Johann Oskarsson http://www.2ndquadrant.com/ |
PostgreSQL Development, 24x7 Support, Training and Services --+--
In response to
pgsql-jdbc by date
|Next:||From: Johann 'Myrkraverk' Oskarsson||Date: 2012-07-10 09:36:55|
|Subject: SQL Error Code Anomaly|
|Previous:||From: Craig Ringer||Date: 2012-07-05 23:29:29|
|Subject: JDBC 4.2 spec: expert group proposed refcursor support|