Hello Kris, hello Oliver,

Kris Jurka schrieb:

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?

I thought about this, too. In this case we deliver a VARCHAR(1073741824) for every "text". I think about this as being very strange alternative to just saying LONGVARCHAR. Also because of my argument of better using getStream() for big text fields IS a good alternative.

Okey, how if we give this as an connection parameter to the driver? describeUnboundTextAs=VARCHAR(1073741824) (default, current behaviour) vs. showTextAs=LONGVARCHAR. This should be extended to show postgres varchar(unbound) in the same type.

IMHO should LONGVARCHAR be the default. If the sql/jdbc spec leaves it relatively undefined, the application (which is generic jdbc and could also use other dbs at the backend), should handle those as relatively undefined, too. And IF the application knows about postgres at the backend, then there is no problem with LONGVARCHAR in the description, too.

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