Re: TypeInfoCache

Daniel Migowski <dmigowski@ikoffice.de> writes: 

    * 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.   

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

1. 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:
   
   
   1. If it wants to get all the contents, it will call getString() anyway, playing the loop into the driver-
   2. If it wants to show a bit of the content, it will call getStream(), and request e.g. just the first 100 chars.

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.

2. 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.

3. 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.

 |¯¯|¯¯|    IKOffice GmbH             Daniel Migowski|  |  |/|                            Mail: dmigowski@ikoffice.de|  | // |  Nordstr. 10               Tel.: +49 (441) 21 98 89 52|  | \\ |  26135 Oldenburg           Fax.: +49 (441) 21 98 89 55|__|__|\|  http://www.ikoffice.de    Mob.: +49 (176) 22 31 20 76           Geschäftsführer: Ingo Kuhlmann, Daniel Migowski           Amtsgericht Oldenburg, HRB 201467           Steuernummer: 64/211/01864