Re: TypeInfoCache

[Resend... the first one seemed to be blank for at least Gregory Stark]

Thank you for your opinions so far. I just looked through the mailing
lists to get the points from former discussions and try to sum it all up
here now:

* At first, VARCHAR as defined by SQL and as used by all other JDBC
drivers always has a upper limit. LONGVARCHAR is for very large
quantities of text, so IMHO returning a "text" or an unrestricted
"varchar" as VARCHAR just breaks the specs and the expectations.
* It is said by Oliver Jowett, that "varchar" (with no limit) and
"text" *are* interchangeable. This is completly true. But then
**both** have to be described by the driver as LONGVARCHAR, not as
VARCHAR. As Tom Lane said, VARCHAR without length is a postgres
specific extension.
* The JDBC-Spec recommends for Fieldtypes of type LONGVARCHAR to use
the getStream() function to get the data, instead of getString()
for VARCHAR. A few years ago the argument was, that an application
should use getString() also for "text" types, since the data is on
the heap already in the current driver design. This has some flaws:
1. The internals of the driver just don't care when programming a
well defined interface like JDBC.
2. An application accessing a LONGVARCHAR might very well just use
the first 100 chars to display a field preview, so a getStream()
call might be completly reasonable. Note it could be up to one Gig
of data.
3. The drivers stores the data internally as a byte[] and wrapped
it into a string when the getString() method is called. This
clones the data anyway, so for very large data getString() is even
more inperformant than getStream() which pulls only a bit of data.
If the application wants everything, it will call getString()
anyway, regardless of the type...
4. An application, that knows the data stored in the db, because
is db schema is by the db developer, can also use getString() on a
LONGVARCHAR if it knows, that the "text" field shouldn't very big.
* A real generic JDBC application will also work with other JDBC
drivers, and will assume all behave the same. As I already stated,
this Link
(http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html)
at 8.9.7 shows what other DB drivers deliver.
* Someone told a few years ago, that all their data in Postgres is
stored as "text" and that exporting this as LONGVARCHAR would
break its application. WTF? He declares unbounded text fields and
then his application should handle them.
* For backwards compatibily we could have users switch from "text"
to "varchar" without bounds, which will also be shown as VARCHAR
with my patch. My patch currently jsut affects the "text" type.
* The current driver implementation breaks ORM mappers, and any
other software, that tries to understand the database schema. As
far as I see, those software completly reasonable relies on a
VARCHAR returning a length

Please give me any good reasons not to apply my patch, with would
further improve standards conformance.
With best regards,

Daniel Migowski

--

|¯¯|¯¯| *IKOffice GmbH Daniel Migowski*
| | |/| Mail: dmigowski(at)ikoffice(dot)de <mailto:dmigowski(at)ikoffice(dot)de>
| | // | Nordstr. 10 Tel.: +49 (441) 21 98 89 52
| | \\ | 26135 Oldenburg Fax.: +49 (441) 21 98 89 55
|__|__|\| http://www.ikoffice.de Mob.: +49 (176) 22 31 20 76

Geschäftsführer: Ingo Kuhlmann, Daniel Migowski
Amtsgericht Oldenburg, HRB 201467
Steuernummer: 64/211/01864