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:
- Find the metadata for the mapping. (Probably a half hour of research, or more, per driver.)
- Define the relation for the data type bindings (a couple of hours, tops).
- 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.)
- Debug and test that the implementation is correct. (Several more hours.)
- 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:
- Is up to date
- Is centralized
- 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
