PostgreSQL JDBC - reading an oidvector field error

Author

reading an oidvector field error

Takeichi Kanzaki Cabrera

2006-01-12, 9:24 am

Hi:
I need to read from the database a oidvector field, I'm using this
code snipped to do this:

Array argsList = rsFunc.getArray("field");
ResultSet rsArgs = argsList.getResultSet();
while (rsArgs.next()) {
String s = rsArgs.getInt(2); //get an error here.
PgDataType type = this.getDataType(s);
args.add(type);
}
rsFunc: is the ResultSet to read the data.
argsList: is and java.sql.Array.

but I get an error of execution time on the line signed, I'm check the
driver source code and I find that this kind of vector is not
supported and I can't change the data type of the field.
Could some one help me to solve this.

--
My regards,
Takeichi Kanzaki Cabrera
Profesor of Computer Programming Techniques and Database Systems
University of Holguin
Cuba

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql
.org so that your
message can get through to the mailing list cleanly

Oliver Jowett

2006-01-13, 3:23 am

Takeichi Kanzaki Cabrera wrote:

> but I get an error of execution time on the line signed,

What is the exact error that you get?

-O

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Takeichi Kanzaki Cabrera

2006-01-16, 1:23 pm

Here is the exception and the stack trace that I get:
org.postgresql.util.PSQLException: Method
org.postgresql.jdbc3.Jdbc3Array. getArrayImpl(long,in
t,Map) is not yet
implemented.
at org.postgresql.Driver. notImplemented(Drive
r.java:580)
at org.postgresql.jdbc2.AbstractJdbc2Array. getArrayImpl(Abstrac
tJdbc2Array.java:232)
at org.postgresql.jdbc2.AbstractJdbc2Array. getResultSetImpl(Abs
tractJdbc2Array.java:291)
at org.postgresql.jdbc2.AbstractJdbc2Array. getResultSet(Abstrac
tJdbc2Array.java:252)
at pgObjects.PgDatabase. loadFunctionsFromDat
abase(PgDatabase.java:893)
at test.Test.showFunctions(Test.java:134)
at test.Test.main(Test.java:166)

Takeichi.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Oliver Jowett

2006-01-16, 8:24 pm

Takeichi Kanzaki Cabrera wrote:
> Here is the exception and the stack trace that I get:
> org.postgresql.util.PSQLException: Method
> org.postgresql.jdbc3.Jdbc3Array. getArrayImpl(long,in
t,Map) is not yet
> implemented.
> at org.postgresql.Driver. notImplemented(Drive
r.java:580)
> at org.postgresql.jdbc2.AbstractJdbc2Array. getArrayImpl(Abstrac
tJdbc2Array.java:232)
> at org.postgresql.jdbc2.AbstractJdbc2Array. getResultSetImpl(Abs
tractJdbc2Array.java:291)
> at org.postgresql.jdbc2.AbstractJdbc2Array. getResultSet(Abstrac
tJdbc2Array.java:252)
> at pgObjects.PgDatabase. loadFunctionsFromDat
abase(PgDatabase.java:893)

This stacktrace doesn't match the line in your code you claim throws an
exception. You originally said:

> Array argsList = rsFunc.getArray("field");
> ResultSet rsArgs = argsList.getResultSet();
> while (rsArgs.next()) {
> String s = rsArgs.getInt(2); //get an error here.
> PgDataType type = this.getDataType(s);
> args.add(type);
> }

but the code path your stacktrace shows is throwing an exception on
getResultSet().

Can you clarify what the code that actually causes the error is?

However the most likely cause is that the array code just does not
understand the OID type -- there is this code in getArrayImpl when an
unsupported array element type is encountered:
[color=darkred]

(this should really throw a more informative exception..)

You could use getString() and parse the array representation yourself as
a workaround, or teach the driver's array code about oids.

-O

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane

2006-01-16, 8:24 pm

Oliver Jowett <oliver@opencloud.com> writes:
> However the most likely cause is that the array code just does not
> understand the OID type -- there is this code in getArrayImpl when an
> unsupported array element type is encountered:

Another problem is that oidvector is not the same as oid[] --- for what
are now entirely historical reasons, they have different external
representations, which is certainly going to confuse any client-side
code trying to parse the data. You'd really need some single-purpose
code in the driver to handle oidvector at all.

In very recent PG releases, you could cast oidvector to oid[] (or maybe
better int8[]) in your query, but unless the JDBC array code copes with
nondefault subscripts, it'll still have trouble:

regression=# select '1 2 3'::oidvector::int8[];
int8
---------------
[0:2]={1,2,3}
(1 row)

regression=#

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Kris Jurka

2006-01-16, 8:24 pm

On Mon, 16 Jan 2006, Tom Lane wrote:

> In very recent PG releases, you could cast oidvector to oid[] (or maybe
> better int8[]) in your query, but unless the JDBC array code copes with
> nondefault subscripts, it'll still have trouble:
>

The JDBC array code throws away nondefault subscripts because the JDBC
spec says that all arrays are 1-indexed. For the most part people don't
want non-default subscripts and only get them via prepending operations
that they didn't expect to alter the indexing (of course these are now
gone in 8.2).

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane

2006-01-16, 8:24 pm

Kris Jurka <books@ejurka.com> writes:
> On Mon, 16 Jan 2006, Tom Lane wrote:
[color=darkred]
> The JDBC array code throws away nondefault subscripts because the JDBC
> spec says that all arrays are 1-indexed.

OK, so casting to int8[] in the query should be a usable workaround.
(You want int8 not int4 because OIDs are unsigned and won't necessarily
fit in an int4.)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Sponsored Links