<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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:<br>
<ul>
<li>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.</li>
<li>It is said by Oliver Jowett, that "varchar" (with no limit) and
"text" <b class="moz-txt-star"><span class="moz-txt-tag">*</span>are<span
class="moz-txt-tag">*</span></b> interchangeable. This is completly
true. But then <b>*both*</b> have to be described by the driver as
LONGVARCHAR, not as VARCHAR. As Tom Lane said, VARCHAR without length
is a postgres specific extension. </li>
<li>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: <br>
1. The internals of the driver just don't care when programming a well
defined interface like JDBC. <br>
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.<br>
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... <br>
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.<br>
</li>
<li>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 (<a
href="http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html">http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html</a>)
at 8.9.7 shows what other DB drivers deliver.<br>
</li>
<li>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.</li>
<li>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.</li>
<li>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</li>
</ul>
Please give me any good reasons not to apply my patch, with would
further improve standards conformance.<br>
With best regards,<br>
<br>
Daniel Migowski<br>
<br>
<br>
<div class="moz-signature">-- <br>
<pre> |¯¯|¯¯| <b>IKOffice GmbH Daniel Migowski</b>
| | |/| Mail: <a
href="mailto:dmigowski(at)ikoffice(dot)de">dmigowski(at)ikoffice(dot)de</a>
| | // | Nordstr. 10 Tel.: +49 (441) 21 98 89 52
| | \\ | 26135 Oldenburg Fax.: +49 (441) 21 98 89 55
|__|__|\| <a href="http://www.ikoffice.de">http://www.ikoffice.de</a> Mob.: +49 (176) 22 31 20 76
Geschäftsführer: Ingo Kuhlmann, Daniel Migowski
Amtsgericht Oldenburg, HRB 201467
Steuernummer: 64/211/01864</pre>
</div>
</body>
</html>