Re: PLJava and Database Meta Data - Mailing list pgsql-jdbc

From Thomas Hallgren
Subject Re: PLJava and Database Meta Data
Date
Msg-id thhal-0tivoAl1MxicqQrb0SvmNhYg9/26uxM@mailblocks.com
Whole thread Raw
In response to Re: PLJava and Database Meta Data  (Markus Schaber <schabios@logi-track.com>)
Responses Re: PLJava and Database Meta Data  (Laszlo Hornyak <kocka@forgeahead.hu>)
List pgsql-jdbc
Markus Schaber wrote:

>Hi, Thomas,
>
>Thomas Hallgren schrieb:
>
>
>
>>>Did you do anything concerning custom datatypes (e. G. PostGIS) yet?
>>>[...]
>>>
>>>
>>Nothing has been done in this area for PLJava yet. I'm definitely in
>>favor of your suggestion. If anything can be done to converge efforts
>>and API's, it should be done.
>>
>>
>
>Okay. Maybe we should also invite other custom datatype authors.
>
>Just out of curiosity (I did not have enough time to take a close look
>at PLJava yet - maybe I should do that first...): How do you currently
>model types like Interval, Money, ByteArray or the native PostgreSQL
>geometry types? (I ask this because in pgjdbc they are currently
>implemented using the same PGobject approach as PostGIS extension types.)
>
>
bytea is mapped to byte[]. The other types are not yet mapped. Where can
I find info about the PostGIS approach?

>And what is your approach to endianness conversion?
>
>
None yet. What types have endian issues and in what way? The PLJava
mapping is using SPI functions directly so we never serialize anything.
PLJava create wrappers for Datum's in the native backend environment.
I'm not sure endian issues ever bites us.

- thomas



pgsql-jdbc by date:

Previous
From: Markus Schaber
Date:
Subject: Re: ERROR: column "total_cost" is of type numeric but expression
Next
From: Antony Paul
Date:
Subject: Re: ERROR: column "total_cost" is of type numeric but expression