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

Re: TypeInfoCache

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Daniel Migowski" <dmigowski(at)ikoffice(dot)de>
Cc: "Oliver Jowett" <oliver(at)opencloud(dot)com>, <pgsql-jdbc(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kris Jurka" <books(at)ejurka(dot)com>
Subject: Re: TypeInfoCache
Date: 2008-01-07 20:08:48
Message-ID: 87ejct4cvj.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
"Daniel Migowski" <dmigowski(at)ikoffice(dot)de> writes:

> I can understand your concerns, if you are used to applications that store
> everything in text-fields on the database. But a problem is only if you have
> such an applicatoin, and forgets about its database fields and uses the
> metadata to remember what its fields have been, now notices the data is in
> LONGVARCHARs, and uses the stream-methods. 

I think that's quite likely though if you build an application and then later
throw some generic tool at it such as a reporting tool, or a schema design
tool, or a migration tool or something like that.

But I wouldn't be too worried about a slowdown. I would be more worried about
having said tool see LONGVARCHAR and throw its hands in the air and refuse to
include it in your reports. Or insist on migrating it to or from MEMO fields
instead of plain strings.

Perhaps this is all just FUD though. I haven't seen such a case myself. I was
under the impression such cases had been previously posted on list but if
you've searched and not found anything then perhaps I'm thinking of some other
scenario.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!

In response to

Responses

pgsql-jdbc by date

Next:From: Ken JohansonDate: 2008-01-08 05:16:55
Subject: Re: Patch for Statement.getGeneratedKeys()
Previous:From: Daniel MigowskiDate: 2008-01-07 19:16:45
Subject: Re: TypeInfoCache

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