On 09/16/18 16:27, Christoph Berg wrote:
>> 20:07:07 CONTEXT: SQL statement "SELECT javatest.assertHasValues( CAST('(1,2)' AS javatest.complextuple), 1, 2)"
Yup, ComplexTuple again....
> 20:06:38 CONTEXT: SQL statement "SELECT javatest.assertHasValues(CAST('(1,2)' AS point), 1, 2)"
Point this time. Sigh. Same issue.
Instead of the silly boot functions, I should probably add to PL/Java a way
to request a CommandCounterIncrement, and have install_jar always use it,
after loading the jar, before running the DDR commands.
> Also, does it have to be that verbose all the time, even if things
> worked?
I don't have very good control yet. There's a page on the wiki for
how I *want* the logging to work:
https://github.com/tada/pljava/wiki/Thoughts-on-logging
... and I also want, eventually, the testing to happen in a more
standard way, such as TAP (tap4j and pgtap). But those goals still
need a substantial development effort. For now, I am stuck with one
example function that writes verbose log messages, and using INFO
for the succeeding ones and WARNING for the failing ones. And even
different PostgreSQL versions have different amounts of verbose
logging that they do for CREATE TYPE commands, etc.
> 20:22:25 Exception in thread "main" java.lang.ClassCastException: sun.org.mozilla.javascript.ConsString cannot be
castto java.lang.String
Could you try changing pljava-packaging/build.xml at line 353 from
computedPath = replacement + computedPath.slice(plen);
to
computedPath = new java.lang.String(replacement + computedPath.slice(plen));
I keep being surprised by differences in the JavaScript interpreter
supplied in different Java runtimes; the unchanged code has worked
without problems on so many. But I *think* this should work on your jdk7
and not break others....
-Chap
