Re: PLJava and Database Meta Data
От | Markus Schaber |
---|---|
Тема | Re: PLJava and Database Meta Data |
Дата | |
Msg-id | 420CB5DF.5090802@logi-track.com обсуждение исходный текст |
Ответ на | PLJava and Database Meta Data (Thomas Hallgren <thhal@mailblocks.com>) |
Ответы |
Re: PLJava and Database Meta Data
|
Список | 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@logi-track.com | www.logi-track.com
Вложения
В списке pgsql-jdbc по дате отправления: