|
|
| Applications |
| Mailing Lists |
| Miscellaneous |
| Operating Systems |
| Programming |
Re: [JDBC] TypeInfoCache
Date: Fri Dec 21 2007 - 16:36:41 EST
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
---------------------------(end of broadcast)---------------------------TIP 5: don't forget to increase your free space map settings Received on Fri Dec 21 16:38:22 2007
This archive was generated by hypermail 2.1.8 : Wed Jun 18 2008 - 23:41:53 EDT
|
Contact Us Legal Notices Order Services Online Pantek Home Privacy Policy IT news Site Map Pantek Library |