Skip site navigation (1) Skip section navigation (2)

Re: TypeInfoCache

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: dmp <danap(at)ttc-cmc(dot)net>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: TypeInfoCache
Date: 2007-12-21 21:36:41
Message-ID: 476C31E9.3030708@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
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


In response to

Responses

pgsql-jdbc by date

Next:From: dmpDate: 2007-12-22 21:04:28
Subject: Re: TypeInfoCache
Previous:From: dmpDate: 2007-12-21 20:18:06
Subject: Re: TypeInfoCache

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group