Re: TypeInfoCache

From: Daniel Migowski <dmigowski(at)ikoffice(dot)de>
To: Kris Jurka <books(at)ejurka(dot)com>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gregory Stark <stark(at)enterprisedb(dot)com>, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: TypeInfoCache
Date: 2007-12-20 11:13:01
Message-ID: 476A4E3D.3050203@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-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hello Kris, hello Oliver,<br>
<br>
Kris Jurka schrieb:<br>
<blockquote cite="mid:Pine(dot)BSO(dot)4(dot)64(dot)0712200547450(dot)15638(at)leary(dot)csoft(dot)net"
type="cite">
<blockquote type="cite">My main concern is that 'text' is a very
common type to use in PostgreSQL based designs, and that JDBC
applications are more likely to understand how to interpret a field
that claims to be VARCHAR than one that is LONGVARCHAR, given that
LONGVARCHAR is a relatively strange type and at best poorly defined.
<br>
</blockquote>
This is my concern as well, which is why I suggested that changing the
precision value might be a better solution.&nbsp; Daniel, any opinion on
that alternative?
<br>
</blockquote>
I thought about this, too. In this case we deliver a
VARCHAR(1073741824) for every "text". I think about this as being very
strange alternative to just saying LONGVARCHAR. Also because of my
argument of better using getStream() for big text fields IS a good
alternative. <br>
<br>
Okey, how if we give this as an connection parameter to the driver?
describeUnboundTextAs=VARCHAR(1073741824) (default, current behaviour)
vs. showTextAs=LONGVARCHAR. This should be extended to show postgres
varchar(unbound) in the same type. <br>
<br>
IMHO should LONGVARCHAR be the default. If the sql/jdbc spec leaves it
relatively undefined, the application (which is generic jdbc and could
also use other dbs at the backend), should handle those as relatively
undefined, too. And IF the application knows about postgres at the
backend, then there is no problem with LONGVARCHAR in the description,
too.<br>
<br>
Best regards,<br>
Daniel Migowski<br>
<br>
<br>
<div class="moz-signature">-- <br>
<pre> |&macr;&macr;|&macr;&macr;| <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&auml;ftsf&uuml;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 2.4 KB

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Daniel Migowski 2007-12-20 12:39:29 Re: TypeInfoCache
Previous Message Daniel Migowski 2007-12-20 10:57:59 Re: TypeInfoCache