Skip site navigation (1) Skip section navigation (2)

Re: Implementing setBinaryStream(int, InputStream, long)

From: "Johann 'Myrkraverk' Oskarsson" <johann(at)2ndquadrant(dot)com>
To: PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Implementing setBinaryStream(int, InputStream, long)
Date: 2012-07-10 09:09:20
Message-ID: byody.x5byody.ehok.ugn3.gnus@asuka.myrkraverk.com (view raw or flat)
Thread:
Lists: pgsql-jdbc
Dave Cramer <pg(at)fastcrypt(dot)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/

In response to

pgsql-jdbc by date

Next:From: Johann 'Myrkraverk' OskarssonDate: 2012-07-10 09:36:55
Subject: SQL Error Code Anomaly
Previous:From: Craig RingerDate: 2012-07-05 23:29:29
Subject: JDBC 4.2 spec: expert group proposed refcursor support

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group