Re: [Patch] JDBC3 Blob support
От | Kris Jurka |
---|---|
Тема | Re: [Patch] JDBC3 Blob support |
Дата | |
Msg-id | Pine.BSO.4.56.0503201658370.32696@leary.csoft.net обсуждение исходный текст |
Ответ на | Re: [Patch] JDBC3 Blob support (Michael Barker <mike@middlesoft.co.uk>) |
Список | pgsql-jdbc |
On Fri, 4 Mar 2005, Michael Barker wrote: > Attached is a patch for Blob and Clob support with JUnits. > I've finally gotten around to reviewing this. The real problem is how to deal with Clobs and encodings. PostgreSQL doesn't really have any specific character large object support and the jdbc driver just layers the Clob type on the existing binary large objects. From the server's perspective it is all just binary data which makes things like length return a number of bytes instead of the number of characters, at least for a multibyte encoding. As I see it we've got a number of poor options: 1) Always use a single byte encoding (like US-ASCII) for storing data even though this cannot store all characters. 2) Always use a multibyte encoding (like UTF-8) for storing data even though this will break many length/positioning methods. 3) Allow the user to select the encoding via a URL parameter. 4) Use the database's server encoding even though this won't always have a JVM equivalent. 5) Use the JVM's encoding. 3) Seems like the only way to really allow a user to pick their poison. Anyone else have an opinion? I suppose we could move a lot of the large object exection from the server to the JDBC driver so it could correctly count characters, but that'd we quite a performance hit. I've attached the version of the patch that I've adjusted slightly and pretty much ignores encoding entirely. Finally some technical comments on the original patch: You shouldn't throw a SQLException without a SQL State. To help enforce this we throw org.postgresql.util.PSQLException that doesn't have a constructor without a SQL state aregument. In the unit tests you write: if (rs.next()) { // do something } else { assertFalse("Message", true); } We don't use assertFalse in order to retain compatibility with junit 3.7. Also this is written more clearly as: assertTrue(rs.next()); // do something Kris Jurka
Вложения
В списке pgsql-jdbc по дате отправления: