From: thomas at tada.se (Thomas Hallgren)
Date: Sun, 01 Oct 2006 15:31:54 +0200
Subject: [Pljava-dev] VarLenTuple example code
In-Reply-To: <451FB6CD.7070808@logix-tt.com>
References: <451BD0B1.8000408@logix-tt.com>	<451BD2F4.60202@tada.se>
	<451BD650.2080201@logix-tt.com>	<451BDB5E.1020107@tada.se>
	<451BE12B.6060809@logix-tt.com>	<451BF32A.7000405@tada.se>
	<451CF211.7000000@logix-tt.com>	<451CFAAD.9030603@tada.se>
	<451D0B0B.4010008@logix-tt.com>	<451D10E0.8020003@tada.se>
	<451D2198.7050202@logix-tt.com>	<451D2849.8030109@tada.se>
	<451D3702.5070802@logix-tt.com>
	<451FAC50.9060100@tada.se> <451FB6CD.7070808@logix-tt.com>
Message-ID: <451FC34A.5070803@tada.se>

Markus Schaber wrote:
> I'd prefer to have a CharSequence in both places (especially as we could
> use a StringBuilder in output then), but as they're @since 1.5, String
> seems the better choice.
>
>   
Yes, I thought about that too. Another thing that could be used is the 
java.io.Reader/Writer but it would only be beneficial for very large 
types. For smaller types we 'd probably loose performance and definitely 
use simplicity.


>> public static void receive(SQLData input, SQLData output) throws
>> SQLException { ... }
>> public static void send(SQLData input, SQLData output) throws
>> SQLException { ... }
>>     
>
> Did you mean SQLInput/SQLOutput instead of SQLData here?
>
>   
Doh, of course!


>> // The SQLData interface
>> //
>> public void readSQL(SQLData input, String typename) throws SQLException
>> { ... }
>> public void writeSQL(SQLData output) throws SQLException { ... }
>>     
>
> SQLInput/SQLOutput here, too, I guess. :-)
>
>   
Yes.


> There's one little problem I currently see: We'll need 2 implementations
> of SQLInput and SQLOutput. One for machine endianness (to parse C), and
> one for network byte order (to parse D).
>
>   
You mean B here, right?


> Or maybe we have both a Big and Little endian implementation, and the
> UDT[] syntax contains a hint on which byte order to use (Big=Network,
> Little, Native=whatever the machine has), with the defaults of Network
> for B and Native for C.
>
>   
I agree that we need two implementations but I think the choice witch 
one to use should be made by PL/Java at all times. The end user doesn't 
need to be exposed to this and PL/Java will always know what it wraps. 
Why introduce the complexity?


> Having two fixed-endian implementations will even be more efficient
> compared to the current one that has an if() in every method, in case
> the Jit does not grasp it.
>
>   
Right. And another thing that struck me is that since all calls origin 
from C-code, and since the backend is inherently single-threaded, it 
would be OK to use one singleton instances of each type. If we do that, 
no objects need to be created when doing send/receive.


> Btw, do you have any idea if and how other databases implement the UDT
> mapping for java?
>
>   
I've done some experimenting with Oracle. They are much closer to the 
SQL 2003 standard where you actually define types along with attributes, 
methods, and constructors. I've brought it up with the PostgreSQL 
community a couple of times but they hasn't shown much interest so far. 
I should mention that the Oracle experiments was performed five years 
ago so a lot might have happened since.

Regards,
Thomas Hallgren