agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

Subject: [Pljava-dev] VarLenTuple example code
Date: Sun, 01 Oct 2006 14:38:37 +0200
Message-ID: <451FB6CD.7070808@logix-tt.com> (raw)
In-Reply-To: <451FAC50.9060100@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>

Hi, Thomas,

Thomas Hallgren wrote:

> I.e. a fullblown type implementation would then have 6 methods (4
> static) and look like this:
> 
> // The new static interface
> //
> public static void input(String input, SQLData output) throws
> SQLException { ... }
> public static String output(SQLData input) throws SQLException { ... }

Using a String in input/output looks like a good compromise between
usability and speed.

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.

> 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?

> // 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. :-)

And a simple mapping for an existing Datatype still needs to implement
only those two, excellent.

> What do you think?

I think it's a good idea. Someone who wants to have the object
representation in input/output and/or send/receive can still use the
readSQL/writeSQL methods of an instance he created itsself. I'll recode
my VarLenTuple example to work this way, and explain the alternatives
using comments.

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).

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.

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.

Btw, do you have any idea if and how other databases implement the UDT
mapping for java?

Thanks,
Markus

view thread (18+ messages)  latest in thread

Message-ID: <451FB6CD.7070808@logix-tt.com>
Permalink:  ../451FB6CD.7070808@logix-tt.com/
Also on:    postgresql.org/message-id/451FB6CD.7070808@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: <451FB6CD.7070808@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