Re: TypeInfoCache

dmp wrote:

> Noticed the asterisked
> rows. These are data types that are specific to PostgreSQL. Granted
> each database is going to have a few of these. Notice the returned
> Class & Type. The 'object' class returned are fine for the Network
> Address types, since the Sun Java JDBC defines methods for objects
> in the getter/setter methods, but the the Interval and Geometric data
> types return specific types that are not defined by the Sun Java JDBC,
> 'PGxxx'. I have learned how to properly handle these types without
> importing them from the org.postgresql driver, but I would call them
> deviants. By the way importing such deviants from a database driver
> in a generic GUI is not particular acceptable.

Can't you just use getString() or getObject() on any type you don't
recognize and let the driver deal with any necessary casting?

> Maybe I'm missing
> something there; Anyway I would think that standard data types should
> really relate more to hardware and the the specifics of the nature of
> program's, in this case database, requirements. Example blob/bytea.
> This is a obvious specific to a database program and so therefore should
> be an extension to the standard data types. If points and circles are going
> to be added is then next perhaps mole?

They're mappings of standard PostgreSQL types, and they use driver
infrastructure that allows adding of specific support for any
user-defined type that happens to get installed in the DB (type
extensibility is a fairly big thing in PostgreSQL, why would we ignore
it?). The geometric types are quite a bit more than just another data
structure, there are various "spatial" indexes and queries you can run
against them. Same is generally true of other custom types, they have
their own indexing and operator behaviour which is why they're there in
the first place.

If you don't want to use the type the driver implements you don't have
to, getString() still works just fine (or somewhat more indirectly -
getObject() -> I don't recognize the returned object -> call toString()
on it)

How would you rather have the driver handle these types, if not in this way?

-O