From: schabi at logix-tt.com (Markus Schaber) Date: Sun, 01 Oct 2006 20:16:28 +0200 Subject: [Pljava-dev] VarLenTuple example code In-Reply-To: <451FC34A.5070803@tada.se> 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> <451FC34A.5070803@tada.se> Message-ID: <452005FC.9070104@logix-tt.com> Hi, Thomas, Thomas Hallgren wrote: >> 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? Yes. Replace D with B. >> 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? I agree. Currently, I don't have any use-case currently for the non-default mappings. And should someone really need a different endianness, pljava can still be adopted, or he/she can put it together byte for byte, or use Integer.swapBytes or such. >> 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. Yes, I agree. So we need 4 static variables: - SQLInput Network Byte Order / Big Endian - SQLInput Machine Byte Order - SQLOutput Network Byte Order - SQLOutput Machine Byte Order On big endian machines, both input variables can even point to the same instance, and the same for the output ones, but I think that's overoptimization. >> 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. So I guess they use their own mapping between the on-disk and java representations, possibly along the pathes of java serialization. Thanks, Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in Europe! www.ffii.org www.nosoftwarepatents.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: