Re: PostgreSQL data types mapped Java classes for JDBC

That's the problem, John.

No single location provides a consistent way to know what all those bindings
are and how they differ. If you wanted to write dynamic code that generates
the correct mapping, you cannot readily create any such implementation. You
must:

1. Find the metadata for the mapping. (Probably a half hour of research,
or more, per driver.)
2. Define the relation for the data type bindings (a couple of hours,
tops).
3. Convert the metadata from source code comments, XML, or whatever to a
table relation (and verify that the details are up to date). (Possibly
several hours.)
4. Debug and test that the implementation is correct. (Several more
hours.)
5. Maintain the list and retest each time either the adapters change or
PostgreSQL changes. (That is, retest what someone else has already tested.)

Let me emphasize what I wrote:

in the information_schema (*or similar*)

As the information_schema is ill-suited, I offered the following
alternative:

*This doesn't have to be packaged with PostgreSQL distributions: it could be
offered as a separate script that people can run [...snip...].*

The *idea* is to maintain this information such that it:

1. Is up to date
2. Is centralized
3. Can be queried with ease

It matters little how it is *implemented*, technically. It could be (in my
preferred order):

- a set of tables in a custom jdbc schema;
- a set of SQL scripts for CREATE TABLE and INSERT statements;
- a set of XML files that conform to an XML schema definition;
- an OpenOffice or Google Docs document (structured to be
machine-readable); or
- a wiki page.

To clarify:

- List all known PostgreSQL-JDBC adapters.
- Map data types to corresponding Java classes for each adapter.
- Maintain the list in a central, public location (ideally that can be
machine transformed into a relational database).
- Distribute the burden of maintaining the list on the shoulders of the
adapter developers.

Dave