Skip site navigation (1) Skip section navigation (2)

Re: PLJava and Database Meta Data

From: Markus Schaber <schabios(at)logi-track(dot)com>
To: Thomas Hallgren <thhal(at)mailblocks(dot)com>
Cc: "pgsql-jdbc(at)postgresql(dot)org" <pgsql-jdbc(at)postgresql(dot)org>,Filip Hrbek <filip(dot)hrbek(at)plz(dot)comstar(dot)cz>
Subject: Re: PLJava and Database Meta Data
Date: 2005-02-11 13:40:47
Message-ID: 420CB5DF.5090802@logi-track.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Hi, Thomas,

Thomas Hallgren schrieb:

>> Okay, so this is fine for primitive types. How does SPI deal with
>> complex types?
>>
> A complex type is represented by a C-structure called HeapTuple. A
> HeapTuple is associated with a TupleDesc that acts as its description.
> The HeapTuple is passed by reference (a C-language pointer) and PLJava
> will obtains its individual values as Datums using a function called
> SPI_getbinval. An individual value may of course be a reference to
> another complex type.
>
> Complex types are created using the function heap_form_tuple.

Okay, sounds good. So it seems that PostGIS/PLJava would need some
understanding of PostGIS internal layout in addition to the canonical
representations it uses on the client side.

Two additional features that are needed to parse the PostGIS internal
rep are optional fields (presence is flagged by bits in other fields)
and arrays (both as complex types). And there must be no issues with
strange alignments.

(All of this how I remember the discussions on the PostGIS mailing list,
I did not do any server-side PostGIS coding myself up to now.)

>> Yes, I have. Especially for large geometries. In our database, we have
>> geometry objects up to 20MB per piece. Also, in PostGIS, send/receive
>> binary representation differs slightly from internal representation (and
>> input/output text is even more overhead).
>
> Ok. We are probably talking about different things. I'm referring to the
> internal C-functions that are executed directly in the backend.

I talked about those backend functions that are declared in CREATE TYPE
statement, which create the canonical text or binary representation
which is sent over to clients (or received from them). This also are the
representations which jdbc works on.

For primitive types, the binary rep equals the internal rep (minus
endianness?), and such conversion is cheap. But this is different for
other types, especially those which are huge in size.

BTW, while loading the PLJava sources from CVS into Eclipse, I found a
small problem in Backend.java, line 127 (the non-1.5 version):

	if(perm.getActions().contains("write") &&
	perm.getName().startsWith("java."))

In Java 1.4 (I tried sun and ibm ones), String has no contains() method.

Markus

--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 z├╝rich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:schabios(at)logi-track(dot)com | www.logi-track.com

In response to

Responses

pgsql-jdbc by date

Next:From: Thomas HallgrenDate: 2005-02-11 13:47:31
Subject: Re: PLJava and Database Meta Data
Previous:From: Thomas HallgrenDate: 2005-02-11 13:19:33
Subject: Re: PLJava and Database Meta Data

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group