uuid datatypes and prepared statements

[Lucas Madar]

I'm running into a weird error when using prepared statements within pl/java:

ERROR:  operator does not exist: uuid = text

This is from a very basic query of "SELECT xxx FROM table WHERE uuid=?". The table's column type is uuid and the java native type is String. It works fine via plain JDBC and also works via pl/java if I use a ::uuid after the query. However, this makes maintaining these queries a mess. I'm running postgres 8.3.7.

Has anyone else experienced this?

Thanks,
Lucas

_______________________________________________
Pljava-dev mailing list
Pljava-dev@...
http://pgfoundry.org/mailman/listinfo/pljava-dev

[Lucas Madar]

I found a workaround, but I'm not sure if there are any bad side effects
to doing it this way: (other than it being ugly)

Before I do any queries with Java UUIDs, I do:
         Oid.registerType(UUID.class, new Oid(2950));
(2950 is the 'magic number' OID from postgresql's types.h)

This seems to have the effect of letting JDBC map Java native UUIDs to
Postgresql UUIDs.

- Lucas

On 6/23/2009 8:00 PM, Lucas Madar wrote:

> I'm running into a weird error when using prepared statements within
> pl/java:
>
> ERROR:  operator does not exist: uuid = text
>
> This is from a very basic query of "SELECT xxx FROM table WHERE
> uuid=?". The table's column type is uuid and the java native type is
> String. It works fine via plain JDBC and also works via pl/java if I
> use a ::uuid after the query. However, this makes maintaining these
> queries a mess. I'm running postgres 8.3.7.
>
> Has anyone else experienced this?
>

_______________________________________________
Pljava-dev mailing list
Pljava-dev@...
http://pgfoundry.org/mailman/listinfo/pljava-dev

[Kris Jurka]

It's not clear what's going on here.  Your initial claim was that the
native Java type was String rather than UUID, but your second message
states that the native type was UUID.

I don't think it will work for doing things like making getObject() on a
uuid value return a UUID type.

pljava also can't do this for you automatically because UUID is new to
the 1.5 JDK while pljava still supports JDK 1.4.  For the regular client
JDBC driver, this functionality is only available in the JDBC4 jar for
this reason.

Kris Jurka

Lucas Madar wrote:

> I found a workaround, but I'm not sure if there are any bad side effects
> to doing it this way: (other than it being ugly)
>
> Before I do any queries with Java UUIDs, I do:
>         Oid.registerType(UUID.class, new Oid(2950));
> (2950 is the 'magic number' OID from postgresql's types.h)
>
> This seems to have the effect of letting JDBC map Java native UUIDs to
> Postgresql UUIDs.
>
> - Lucas
>
> On 6/23/2009 8:00 PM, Lucas Madar wrote:
>> I'm running into a weird error when using prepared statements within
>> pl/java:
>>
>> ERROR:  operator does not exist: uuid = text
>>
>> This is from a very basic query of "SELECT xxx FROM table WHERE
>> uuid=?". The table's column type is uuid and the java native type is
>> String. It works fine via plain JDBC and also works via pl/java if I
>> use a ::uuid after the query. However, this makes maintaining these
>> queries a mess. I'm running postgres 8.3.7.
>>
>> Has anyone else experienced this?
>>
> _______________________________________________
> Pljava-dev mailing list
> Pljava-dev@...
> http://pgfoundry.org/mailman/listinfo/pljava-dev

_______________________________________________
Pljava-dev mailing list
Pljava-dev@...
http://pgfoundry.org/mailman/listinfo/pljava-dev

[Lucas Madar]

Sorry if I wasn't clear... I had spent a few hours trying to figure out
the problem and it was getting late. I was trying both for Strings and
native UUIDs, because I thought that could be a potential solution. The
solution worked except for setting null UUIDs, as there is no SqlType
that corresponds to them in PL/Java.

The problem turns out to be in postgresql itself and only manifests in
prepared statements. In fact, the error occurs when preparing the
statement the first time, not when actually querying anything. Since the
prepared statement is using a 'text' type for the column value and the
actual column type is uuid, this is an implicit cast from text to uuid,
which postgresql doesn't allow. I worked around this with CREATE CAST
and a custom C driver (yuck). I noticed that you're a postgresql
developer as well; is this something that is planned to be fixed in 8.4?

Thanks,
Lucas

On 6/24/2009 11:44 AM, Kris Jurka wrote:

> It's not clear what's going on here.  Your initial claim was that the
> native Java type was String rather than UUID, but your second message
> states that the native type was UUID.
>
> I don't think it will work for doing things like making getObject() on
> a uuid value return a UUID type.
>
> pljava also can't do this for you automatically because UUID is new to
> the 1.5 JDK while pljava still supports JDK 1.4.  For the regular
> client JDBC driver, this functionality is only available in the JDBC4
> jar for this reason.
>
> Kris Jurka
>
> Lucas Madar wrote:
>> I found a workaround, but I'm not sure if there are any bad side
>> effects to doing it this way: (other than it being ugly)
>>
>> Before I do any queries with Java UUIDs, I do:
>>         Oid.registerType(UUID.class, new Oid(2950));
>> (2950 is the 'magic number' OID from postgresql's types.h)
>>
>> This seems to have the effect of letting JDBC map Java native UUIDs
>> to Postgresql UUIDs.
>>
>> - Lucas
>>
>> On 6/23/2009 8:00 PM, Lucas Madar wrote:
>>> I'm running into a weird error when using prepared statements within
>>> pl/java:
>>>
>>> ERROR:  operator does not exist: uuid = text
>>>
>>> This is from a very basic query of "SELECT xxx FROM table WHERE
>>> uuid=?". The table's column type is uuid and the java native type is
>>> String. It works fine via plain JDBC and also works via pl/java if I
>>> use a ::uuid after the query. However, this makes maintaining these
>>> queries a mess. I'm running postgres 8.3.7.
>>>
>>> Has anyone else experienced this?
>>>
>> _______________________________________________
>> Pljava-dev mailing list
>> Pljava-dev@...
>> http://pgfoundry.org/mailman/listinfo/pljava-dev
>

_______________________________________________
Pljava-dev mailing list
Pljava-dev@...
http://pgfoundry.org/mailman/listinfo/pljava-dev