Re: Implementing setBinaryStream(int, InputStream, long)
От | Johann 'Myrkraverk' Oskarsson |
---|---|
Тема | Re: Implementing setBinaryStream(int, InputStream, long) |
Дата | |
Msg-id | byody.x5byody.ehok.ugn3.gnus@asuka.myrkraverk.com обсуждение исходный текст |
Ответ на | Re: Implementing setBinaryStream(int, InputStream, long) (Dave Cramer <pg@fastcrypt.com>) |
Список | pgsql-jdbc |
Dave Cramer <pg@fastcrypt.com> writes: > Also it would be nice if a test case came with this patch. I've written a testsuite for this patch. It tests the three cases of length < 0, length > Integer.MAX_VALUE and that it actually works. The testcase that tests if the feature is working properly uses the prepared statement SELECT ?::TEXT and compares the returned hex value. This is not a good idea because it depends on the bytea -> text conversion which has changed in recent Postgres versions, right? What is a good way to isolate the test code from version specific behaviour? In this case, whether bytea to text is _escape_ or _hex_. Now that we're using git, is there any point in CVS identification strings in new files? Also, I only state Copyright 2012 for new files, and not 20xx-2012, right? When tests are catching SQL exceptions and comparing the error code, do we want to hard code them, or refer to PSQLState constants? Personally, I do not believe in using the same constants in test and production code. -- Johann Oskarsson http://www.2ndquadrant.com/ |[] PostgreSQL Development, 24x7 Support, Training and Services --+-- | Blog: http://my.opera.com/myrkraverk/blog/
В списке pgsql-jdbc по дате отправления: