agora inbox for pljava-dev@postgresql.org
help / color / mirror / Atom feedSubject: [Pljava-dev] VarLenTuple example code
Date: Sun, 01 Oct 2006 15:31:54 +0200
Message-ID: <451FC34A.5070803@tada.se> (raw)
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>
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
view thread (18+ messages) latest in thread
Message-ID: <451FC34A.5070803@tada.se>
Permalink: ../451FC34A.5070803@tada.se/
Also on: postgresql.org/message-id/451FC34A.5070803@tada.se
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: <451FC34A.5070803@tada.se>
* 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