[Pljava-dev] Possible to override default type mappings?

Thomas Hallgren wrote:
> Eric Faulhaber wrote:
>> Hello,
>>
>> In order to use a pre-existing Java library which works with specialized
>> implementations of the basic SQL types (varchar, int, etc.), I am trying
>> to override the default type mappings for these types to use our
>> specialized classes instead of java.lang.String, java.lang.Integer, etc.
>>
>> Is this possible? I keep getting an error:
>>
> No, it's not possible and that's very intentional. I can't see any
> use-case where replacing the default mapping for a basic type would make
> sense. Perhaps you could elaborate this? Would using SQL domains help you?
>

My question was based on my initial [mis]understanding that the type
mapping was one-way. That is, I thought the mappings were isolated
within the scope of PL/Java only, such that the backend could use
standard SQL types, and would leave it to PL/Java to perform the mapping
to/from a custom Java class for function parameters and return values.
I didn't realize that a custom type defined with PL/Java was "installed"
into the backend using PG's UDT architecture. I see now that this is
the case and that it would be problematic/dangerous to redefine the
basic types in the backend.

The reason for all this is that we have an existing Java library which
uses non-J2SE wrappers for int, double, boolean, etc. These are
necessary to support the very specialized semantics of a runtime
environment for a legacy application. We actually want to keep default
types in the database schema, but map these to our specialized types in
the JVM only. Our wrapper types are a middle tier necessity only, we
don't want to "pollute" the backend with them. I believe SQL domains
are meant to solve a different problem and are not appropriate here.

I was trying to avoid re-implementing our existing function library to
use J2SE wrapper types. My compromise was to create a "shim" API
exclusively for PL/Java's use, which accepts and returns only primitives
or J2SE wrappers, but which creates instances of our custom types and
invokes methods in our existing library under the covers. It works
generally, but it adds an extra layer which is tedious to maintain.
Nevertheless, it is worth the effort, given the advantages of executing
the functions at the server.

>> There are no errors at this stage and it looks as though the type
>> mappings were set up correctly:
>>
>> test_db=# select * from sqlj.typemap_entry;
>> mapid | javaname | sqlname
>> -------+----------------+--------------------
>> 46 | test.integer | pg_catalog.int4
>> 47 | test.character | pg_catalog.varchar
>>
> Hmm, it should yield and error. I'll have to look into that.
>
> Regards,
> Thomas Hallgren

Thanks for your response, and thanks for creating and supporting a
useful and innovative project.

Regards,
Eric Faulhaber