Re: TypeInfoCache - Mailing list pgsql-jdbc

Hello Tom,<br /><br /> Tom Lane schrieb: <blockquote cite="mid:11679.1198165116@sss.pgh.pa.us" type="cite"><pre
wrap="">DanielMigowski <a class="moz-txt-link-rfc2396E"
href="mailto:dmigowski@ikoffice.de"><dmigowski@ikoffice.de></a>writes: </pre><blockquote type="cite"><pre
wrap="">   * At first, VARCHAR as defined by SQL and as used by all other JDBC     drivers always has a upper limit.
LONGVARCHARis for very large     quantities of text, so IMHO returning a "text" or an unrestricted     "varchar" as
VARCHARjust breaks the specs and the expectations.   </pre></blockquote><pre wrap="">
 
Unfortunately, LONGVARCHAR is no more standard than TEXT, at least
as far as the non-JDBC world is concerned.

I concur with the complaints that LONGVARCHAR is likely to prompt
applications to do things that might be enormously inefficient overkill
for typical-size fields.  If the driver had a way to know which fields
are likely to be wide, it'd be OK to translate them to LONGVARCHAR,
but I'm dubious about doing that for text fields in general.
        regards, tom lane</pre></blockquote> Okey, we have 3 Scenarios:<br /><ol><li>Scenario 1: A JDBC conformant
applicationtrying to use JDBC to do arbitrary things with arbitrary databases and artbitrary JDBC drivers (Like some
generalJDBC database manager). This application indeed has to use getStream() for LONGVARCHAR fields, because it cannot
knowabout the size of the contents. But there is a difference in what the application wants to do with that stream:<br
/><br/><ol><li>If it wants to get all the contents, it will call getString() anyway, playing the loop into the
driver-<li>Ifit wants to show a bit of the content, it will call getStream(), and request e.g. just the first 100
chars.</ol></ol><blockquote>Ineither case it is BETTER to deliver a LONGVARCHAR because now the application can DECIDE
whatto do. For VARCHAR it will always use getString(), because of the spec.<br /></blockquote><ol
start="2"><li>Scenario2: The application either knows about the data itself, because it provided DDL. Or the
applicationhas to work with different DBs and different Drivers but is the same application, and just has some
O/R-Mappingbelow its feet. Every other DBMS behaves by returning LONGVARCHAR, only for PostgreSQL this application has
towrite a workaround and to use the VARCHAR.</ol><ol start="3"><li>Scenario 3: Specialized Java Application with one
driverand one postgres db knowing exactly about the backend and just using JDBC as an abstraction. This app can easily
workaround the LONGVARCHAR because it knows the containing data anyway.</ol> Sorry, but no Scenario profits from the
decisionof not returning LONGVARCHAR. Does someone have any scenario that does?<br /><br /> With best regards,<br />
DanielMigowski<br /><br /><br /><br /><div class="moz-signature">-- <br /><pre> |¯¯|¯¯|    <b>IKOffice GmbH
DanielMigowski</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>