agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

Subject: [Pljava-dev] VarLenTuple example code
Date: Sun, 01 Oct 2006 20:16:28 +0200
Message-ID: <452005FC.9070104@logix-tt.com> (raw)
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>

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;

view thread (18+ messages)

Message-ID: <452005FC.9070104@logix-tt.com>
Permalink:  ../452005FC.9070104@logix-tt.com/
Also on:    postgresql.org/message-id/452005FC.9070104@logix-tt.com

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pljava-dev@postgresql.org
  Subject: Re: [Pljava-dev] VarLenTuple example code
  In-Reply-To: <452005FC.9070104@logix-tt.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox