[Pljava-dev] Issue 21 Re: PL/java kills unicode chars?

Hi Chap,

I'm not sure what you're asking here. It is always OK to use methods in the Java library without a thread lock provided
there's absolutely no chance that any new threads that they might start calls back into the backend. Don't see how any
of the methods you mention could do that.

Or perhaps you mean that you would like to call these methods from SQL without imposing a thread lock? In that case,
yes, that's OK too as long as they in turn do not call anything that a user has written and obey by the rule stated above.

That said, I'm very much in favor of solutions that doesn't require the user to have specific knowledge about encodings.
Once configured, it should just work regardless. I.e. conversion to/from UTF should ideally be invisible and no special
calls from SQL should be needed.

In order to advice on a good solution I'd like to first know exactly what the problem and it's possible solutions are.

- thomas

On 2015-09-24 01:39, Chapman Flack wrote:
> Question (mostly for Thomas),
>
> In working on issue 21, would it be acceptable to add specialized
> calls (in JNICalls or elsewhere), for calling up into a very select
> few Java methods without releasing and reacquiring the threadlock?
>
> such as...
>
> CharSequence.toString()
> java.nio.Buffer.position()
> java.nio.CharBuffer.wrap(CharSequence)
> java.nio.charset.CharsetDecoder.decode(ByteBuffer)
> java.nio.charset.CharsetEncoder.encode(CharBuffer,ByteBuffer,boolean)
>
> They could be called rather often ;) and the monitor operations could be
> overkill; no point giving another thread access to the backend during
> such a simple operation.
>
> I like your comments in the source saying "Would be nice if a direct
> conversion from UTF16 was provided." This task is like some kind of
> "you can't get there from here" Vaudeville routine. Between what's
> provided in PG and what's in Java there are at least three different APIs
> to approach the problem with, and for *each one* there seems to be *one*
> feature lacking that necessitates going the long way around, too many
> pallocs/copies. etc.
>
> Or Kafka. It could be Kafka.
>
> -Chap
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev at lists.pgfoundry.org
> http://lists.pgfoundry.org/mailman/listinfo/pljava-dev