Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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: unknown_filename
Description: text/html (2.4 KB)

In response to

pgsql-jdbc by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group