References: <56945E0E.3000104@hogranch.com> <56945EA8.9090505@anastigmatix.net> <56946D05.9050508@anastigmatix.net> <5698E79E.6040904@hogranch.com> From: Chapman Flack Message-ID: <56990F46.2000309@anastigmatix.net> Date: Fri, 15 Jan 2016 10:24:54 -0500 MIME-Version: 1.0 In-Reply-To: <5698E79E.6040904@hogranch.com> Subject: Re: [Pljava-dev] built, now how to install? Content-Type: text/plain; charset="us-ascii" 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@lists.pgfoundry.org http://lists.pgfoundry.org/mailman/listinfo/pljava-dev