[Pljava-dev] VarLenTuple example code

From: schabi at logix-tt(dot)com (Markus Schaber)
To:
Subject: [Pljava-dev] VarLenTuple example code
Date: 2006-10-01 18:16:28
Message-ID: 452005FC.9070104@logix-tt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

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: <http://lists.pgfoundry.org/pipermail/pljava-dev/attachments/20061001/282bad19/attachment.bin>

In response to

Browse pljava-dev by date

  From Date Subject
Next Message Markus Schaber 2006-10-01 19:03:23 [Pljava-dev] SQLInput and SQLOutput implementations
Previous Message Thomas Hallgren 2006-10-01 13:31:54 [Pljava-dev] VarLenTuple example code