Re: TypeInfoCache
От | Daniel Migowski |
---|---|
Тема | Re: TypeInfoCache |
Дата | |
Msg-id | 476A6281.6090008@ikoffice.de обсуждение исходный текст |
Ответ на | Re: TypeInfoCache (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
Kris Jurka schrieb:
With best regards,
Daniel Migowski
--
On Thu, 20 Dec 2007, Oliver Jowett wrote: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.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?
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 по дате отправления: