Kris Jurka pisze:
>
> Currently the driver implements DatabaseMetaData.getUDTs by considering
> only complex types and domains as UDTs and the javadoc for that method
> seems to imply that's correct. Perhaps the JDBC spec isn't prepared for
> the extensibility that pg offers, but you'll need to reconcile these two
> definitions if you want to qualify all types outside pg_catalog.
From my point of view getUDTs is working just fine.
> My recollection was that making all type operations in the driver schema
> qualified was more work that a simple change to TypeInfoCache, but I
> don't recall the details, so I'd like to see what you come up with.
> While you wouldn't want to report the pg_catalog parts of base types you
> would need a way to ensure that if you had myschema.int4 it wouldn't
> conflict.
Maybe I was to optimistic that is so easy to implement this, but it is
not so hard too. The main change is to use qualified names within
TypeCacheInfo everywhere it is possible, that means that even basic
types should be presented with its schema (pg_catalog). Of course that
change will force other changes especially in TypeCacheInfo internal sql
queries and other places where type name is taken/provided. With this
changes ResultSetMetaData.getColumnTypeName() will return local name for
basic types (that is a type that qualified name's
startsWith("pg_catalog")) and qualified name for all other types.
> Could explain in more detail how you're mapping these UDTs to Java?
> Using PGobject? I'm not sure how you'd map without an implemention of
> SQLData/Input/Output.
I have made a wrapper for JDBC classes, that override default implementation
of JDBC driver and when needed (ResultSet.getObject()) it translates sql
types to Java types and vice-versa (PreparedStatement.setObject()). My
implementation works only for composite types, cause composite type have
same structure of string representation.
Best wishes,
ML
