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?

Yes, and this is exactly what the application does. The same is not true of
the setter methods. When I first created the TableEntryForm it did not pay
attention to any of the data types, but obvious ones like date and time.
The form would just use setObject(). Later it was decided to do some checks
on data before it was submitted to the database, for instance numeric
characters were sent for integers. This then involved checking and using
the appropriate java.sql.Type setter for the type. Any types not caught
would
drop through and use setObject. With the PostgreSQL JDBC driver this does
not work. You have to use the appropriate setter, unfortunately the standard
JDBC does not define the interval, network, or geometric types. So you have
to CAST or import the type from the postgreSQL driver. Since the MyJSQLView
program also supports MySQL the program would then need the postgreSQL
driver to function even if a user only wanted to use MySQL. This creates a
dependency outside of the standard JDBC. Well a CAST was the solution, but
still the application has to catch all defined data types and not let
them drop through
to a default setObject().

> 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?).

I'm sorry I can not really answer this. All you have done is state a
reality.
We already know PostgreSQL is calling these standard types and or course
if they are then the driver I guess would then support them. If you call
them
one of the standard types then again yes users can use them for a basis for
building more complex user-defined types. Extendibility is an admirable
feature for a program, I guess my argument here is that maybe it should be
limited with regard to data types. I have never seen in my limited
experience
a programing language that defined a point as a data type. In reality it
is a
concept that is composed of data types, real/integer numbers. Yes it is nice
to have these predisposed types, but a user could of created a point through
a user-defined type just like an example I saw in the manual regarding a
complex type.

> 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.

Now were are getting somewhere. If the internals of the database are using
these geometric types in the algorithms for indexes and queries then perhaps
they are justified as some form of data structure. Notice that I have quoted
you from above, you are now even calling them data structures, and not
types. If this is the case then it might be understandable in defining them
as available 'data types'. If this is not the case then you are again
just making
a statement in support of providing the ability to use something that was
created. If you create a type then obviously you have to provide indexing
and operators for it, the latter does not justify its existence.

> 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)

I already answered this.

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

I would rather not have to CAST or import non-standard types which are not
defined in the Sun JDBC. If you wish to have them at least make the driver
except a generic string setter method like the getter. Which is where we
started
with this thread in which I think was done. I have been busy trying to get a
PostgreSQL export working so I have not checked. Anyway I think I'm happy,
how about everyone else? I really do appreciate the support/information
this forum
and the others PostgreSQL provides. Thanks guys/gals.

danap.