Re: TypeInfoCache - Mailing list pgsql-jdbc

Thank you for your opinions so far. I just looked through the mailing lists to get the points from former discussions
andtry to sum it all up here now:<br /><ul><li>At first, VARCHAR as defined by SQL and as used by all other JDBC
driversalways 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>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
thedriver as LONGVARCHAR, not as VARCHAR. As Tom Lane said, VARCHAR without length is a postgres specific extension.
<li>TheJDBC-Spec recommends for Fieldtypes of type LONGVARCHAR to use the getStream() function to get the data, instead
ofgetString() 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
ofthe driver just don't care when programming a well defined interface like JDBC. <br /> 2. An application accessing a
LONGVARCHARmight very well just use the first 100 chars to display a field preview, so a getStream() call might be
completlyreasonable. 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
largedata getString() is even more inperformant than getStream() which pulls only a bit of data. If the application
wantseverything, it will call getString() anyway, regardless of the type... <br /> 4. An application, that knows the
datastored 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>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>)
at8.9.7 shows what other DB drivers deliver.<br /><li>Someone told a few years ago, that all their data in Postgres is
storedas "text" and that exporting this as LONGVARCHAR would break its application. WTF? He declares unbounded text
fieldsand then his application should handle them.<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>The current driver implementation breaks ORM mappers, and any other software, that tries to understand
thedatabase schema. As far as I see, those software completly reasonable relies on a VARCHAR returning a length</ul>
Pleasegive 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@ikoffice.de">dmigowski@ikoffice.de</a>| | // |  Nordstr. 10               Tel.: +49 (441) 21 98
8952|  | \\ |  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>