Kris Jurka schrieb:
On Thu, 20 Dec 2007, Oliver Jowett wrote:
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.
This is my concern as well, which is why I suggested that changing the precision value might be a better solution. Daniel, any opinion on that alternative?
Btw., you say that "JDBC applications" are more likely to understand how to interpret a VARCHAR field, than an LONGVARCHAR field. Which? I don't know any.And currently a JDBC application (Chrystal Reports) broke, because we did't send a LONGVARCHAR! Every JDBC application should be able to handle both, since JDBC defines both. And, most important, both types can, according to JDBC spec, treated equally (same access functions,etc.). So we shouldn't create a broken driver for applications, that _might_ be broken. And if they are, a parameter option should be a fair deal to give to the driver, to let bad behaving applications work. We don't have to stick to bugs just for backwards compatibility, don't we? We are not Microsoft, i think.
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
