Re: [Pljava-dev] built, now how to install?

On 01/15/2016 07:35 AM, John R Pierce wrote:

> (grrr, why isn't maven packaged as an RPM in one of the major rpm
> repos?? the one I found wanted to drag in openjdk 1.6.0)

I don't know, but because it's pure Java and will go out itself
and fetch everything else it needs the first time you run it,
there is really no need to fret over finding an installer for it.
You just grab a tarball or zipball (why, in 2016, are we still
asking you "tar or zip?" before you can download some Java code? :)
from http://maven.apache.org/download.cgi and extract it in your
favorite temp directory and run bin/mvn and watch the downloads fly.

If you edit your .m2/settings.xml to put the repository in temp
space too, it all goes away when you no longer need it.

> test failed
> with what appear to be character encoding errors. my test server was
> running en_US.UTF8, while I suspect this production site uses
> POSIX/SQLASCII...

If the server is SQL_ASCII and the only failing test was the
UnicodeRoundTripTest, then PL/Java is working and that's as good
as it's going to get. That particular test doesn't even have a
definable meaning when the server encoding is SQL_ASCII.

To elaborate, that test is the regression test for bug 21
https://github.com/tada/pljava/issues/21 and it's there to
confirm that PL/Java will faithfully roundtrip all Unicode
characters from and to the server encoding. But out of all
the available server encodings, SQL_ASCII is the one that says
"I am ASCII for codes in the ASCII range, and I allow codes
outside that range but _nobody defines what they mean_ except
maybe the application developer, one dares to hope."

(Come to think of it, I bet my test as written will only
succeed for server encoding UTF8. It should really test that
the mapping is faithful _for all characters representable in
the server encoding_ and then it would succeed with all of the
normal, defined encodings. It would still fail with SQL_ASCII
because that's an "encoding" that's only defined for a fraction
of its codes.)

So, this site's situation can be broken into cases:

Case 1 (easiest): server encoding is SQL_ASCII, database
doesn't contain any strings with non-ASCII data (or none that
will be poked at in Java code, anyway). Everything will work
fine.

Case 2: Server encoding is SQL_ASCII, database contains some
non-ASCII data, all of which actually is in some one standard
encoding. This begs the question why not set the server encoding
to *be* that encoding and then everything will just work, but
perhaps that would involve disruptive downtime. It could be
possible to add a PL/Java GUC for that situation, something like
pljava.i_guarantee_my_sqlascii_data_actually_happens_to_be='latin1'
or whatever. That doesn't exist at the moment but would not be
prohibitively hard.

Case 3: Server encoding is SQL_ASCII, database contains some
non-ASCII data in more than one encoding, where the application
somehow knows which encoding is used where. That's completely
possible since SQL_ASCII doesn't guarantee anything; it permits
the kind of encoding flexibility the SQL standard allows by using
N'' strings, only instead of the encoding being known for each
N'' string, it isn't known anywhere but within the application.
There is no way to expect PL/Java to make sense out of that
transparently, and the rigorous solution would be for the app
to use bytea as the type of things passed to and from Java,
and explicitly apply convert_to()/convert_from() where the
application knows the encoding. It's verbose but correct;
Python 3 had to walk the same road.

I should probably put this in the docs somewhere.

Do you know which case your site is dealing with?

-Chap
_______________________________________________
Pljava-dev mailing list
Pljava-dev(at)lists(dot)pgfoundry(dot)org
http://lists.pgfoundry.org/mailman/listinfo/pljava-dev