Re: TypeInfoCache

From: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-jdbc(at)postgresql(dot)org, Oliver Jowett <oliver(at)opencloud(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>
Subject: Re: TypeInfoCache
Date: 2007-12-20 15:55:47
Message-ID: 476A9083.80407@ikoffice.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Tom,<br>
<br>
Tom Lane schrieb:
<blockquote cite="mid:11679(dot)1198165116(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap="">Daniel Migowski <a class="moz-txt-link-rfc2396E" href="mailto:dmigowski(at)ikoffice(dot)de">&lt;dmigowski(at)ikoffice(dot)de&gt;</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. 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.
</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 application trying to use JDBC to
do arbitrary things with arbitrary databases and artbitrary JDBC
drivers (Like some general JDBC database manager). This application
indeed has to use getStream() for LONGVARCHAR fields, because it cannot
know about the size of the contents. But there is a difference in what
the application wants to do with that stream:<br>
<br>
</li>
<ol>
<li>If it wants to get all the contents, it will call getString()
anyway, playing the loop into the driver-</li>
<li>If it wants to show a bit of the content, it will call
getStream(), and request e.g. just the first 100 chars.</li>
</ol>
</ol>
<blockquote>In either case it is BETTER to deliver a LONGVARCHAR
because now the application can DECIDE what to do. For VARCHAR it will
always use getString(), because of the spec.<br>
</blockquote>
<ol start="2">
<li>Scenario 2: The application either knows about the data itself,
because it provided DDL. Or the application has to work with different
DBs and different Drivers but is the same application, and just has
some O/R-Mapping below its feet. Every other DBMS behaves by returning
LONGVARCHAR, only for PostgreSQL this application has to write a
workaround and to use the VARCHAR.</li>
</ol>
<ol start="3">
<li>Scenario 3: Specialized Java Application with one driver and one
postgres db knowing exactly about the backend and just using JDBC as an
abstraction. This app can easily work around the LONGVARCHAR because it
knows the containing data anyway.</li>
</ol>
Sorry, but no Scenario profits from the decision of not returning
LONGVARCHAR. Does someone have any scenario that does?<br>
<br>
With best regards,<br>
Daniel Migowski<br>
<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>

Attachment Content-Type Size
unknown_filename text/html 3.6 KB

In response to

Responses

Browse pgsql-jdbc by date

  From Date Subject
Next Message danap 2007-12-20 16:15:14 Re: TypeInfoCache
Previous Message Tom Lane 2007-12-20 15:38:36 Re: TypeInfoCache