Re: TypeInfoCache - Mailing list pgsql-jdbc
| From | Daniel Migowski |
|---|---|
| Subject | Re: TypeInfoCache |
| Date | |
| Msg-id | 476A4AB7.90509@ikoffice.de Whole thread Raw |
| In response to | Re: TypeInfoCache (Tom Lane <tgl@sss.pgh.pa.us>) |
| Responses |
Re: TypeInfoCache
(Tom Lane <tgl@sss.pgh.pa.us>)
|
| List | pgsql-jdbc |
[Resend... the first one seemed to be blank for at least Gregory Stark]
Thank you for your opinions so far. I just looked through the mailing lists to get the points from former discussions and try to sum it all up here now:
With best regards,
Daniel Migowski
Thank you for your opinions so far. I just looked through the mailing lists to get the points from former discussions and try to sum it all up here now:
- 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.
- It is said by Oliver Jowett, that "varchar" (with no limit) and "text" *are* interchangeable. This is completly true. But then *both* have to be described by the driver as LONGVARCHAR, not as VARCHAR. As Tom Lane said, VARCHAR without length is a postgres specific extension.
- The JDBC-Spec recommends for Fieldtypes of type LONGVARCHAR to use the getStream() function to get the data, instead of getString() for VARCHAR. A few years ago the argument was, that an application should use getString() also for "text" types, since the data is on the heap already in the current driver design. This has some flaws:
1. The internals of the driver just don't care when programming a well defined interface like JDBC.
2. An application accessing a LONGVARCHAR might very well just use the first 100 chars to display a field preview, so a getStream() call might be completly reasonable. Note it could be up to one Gig of data.
3. The drivers stores the data internally as a byte[] and wrapped it into a string when the getString() method is called. This clones the data anyway, so for very large data getString() is even more inperformant than getStream() which pulls only a bit of data. If the application wants everything, it will call getString() anyway, regardless of the type...
4. An application, that knows the data stored in the db, because is db schema is by the db developer, can also use getString() on a LONGVARCHAR if it knows, that the "text" field shouldn't very big. - A real generic JDBC application will also work with other JDBC drivers, and will assume all behave the same. As I already stated, this Link (http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html) at 8.9.7 shows what other DB drivers deliver.
- Someone told a few years ago, that all their data in Postgres is stored as "text" and that exporting this as LONGVARCHAR would break its application. WTF? He declares unbounded text fields and then his application should handle them.
- For backwards compatibily we could have users switch from "text" to "varchar" without bounds, which will also be shown as VARCHAR with my patch. My patch currently jsut affects the "text" type.
- The current driver implementation breaks ORM mappers, and any other software, that tries to understand the database schema. As far as I see, those software completly reasonable relies on a VARCHAR returning a length
With best regards,
Daniel Migowski
--
|¯¯|¯¯| 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
pgsql-jdbc by date: