Scrolling, Counting (the whole shebang?)

Question

Bear with me here, this one's causing me headaches and sleepless nights (and I'm not exaggerating. While this issue sits in Bugzilla the boss cannot be silenced.)
<cliche>The story so far...</cliche>
An implementation of a scrolling result set I built recently for one of the queries in our system was done like this (The database system in question is Postgresql, btw):
(1) Count the rows using a SELECT count(*) ...
(2) Get a cursor with DECLARE CURSOR FOR SELECT ...
(3) Use FETCH to grab rows, MOVE to move the cursor, etc.
(4) Finish up at some point in the future with a CLOSE.
Now...
The entire reason we went through this horror was because ResultSet in Postgres isn't implemented using native Postgres cursors. This made the development team uneasy (we thought the performance wouldn't be up to scratch) so we eventually decided we would go for a somewhat more brute-force way of using Postgres' built-in commands. The result, a very fast scrolling result set, which works fine, for the one or two pages in our system which use it.
But (there is ALWAYS a but, right?)...
Since the DECLARE CURSOR, FETCH, MOVE, and CLOSE statements are not in the SQL standard, the query doesn't work under, say, DB2. Likelihood is it wouldn't work under any other database at all. And for portability's sake, we're considering this to be a bad thing.
In addition to this, the need to get the count separately from the query itself means that in every place where we do a SELECT, we have to have an equivalent SELECT to do the count (which in some cases can bear little or no resemblance to the one used to do the query.)
So...
Question 1: Is doing an 'ordinary' SELECT query, holding the ResultSet in memory and simply reading off row by row only parts of it considered 'safe', where 'safe' is defined by not causing OutOfMemoryError for queries in the order of 10,000-100,000 results?
Now, we require a count of the number of the results. In our existing system this is the slowest part of the process because the SELECT count(*) takes orders of magnitude more time to execute than the DECLARE CURSOR. That is, the DECLARE CURSOR takes about 10ms, and the SELECT count(*) can take a minute, depending on the size of the result set, presumably because the DECLARE CURSOR doesn't actually do the query, and that the query executes as you fetch more results from it, or in the background. (Beats me, anything involving databases is magic as far as I'm concerned.)
Since we 'require' the count though (for the user interface only, despite the fact that it cripples the query speed somewhat), we might be able to get away with doing it this way, so...
Question 2: Would doing the following set of commands likely take the same amount of time to run (or less, or more), compared to doing the SELECT count(*)?
PreparedStatement ps = /* insert code here ;-) */
ResultSet rs = ps.executeQuery();
rs.afterLast();
int numRows = rs.getRow();
rs.beforeFirst();I guess another part of Question 2 is, is that sequence of commands considered an 'acceptable' way of counting the number of rows returned? It seems to me they would take a long time to run, but sob I don't know.
The main thing is, we have an extraordinarily large number of different queries in this system, and all of them pretty much use joins of some sort, and all of them are incredibly complex. The system as a whole is quite monolithic, which is why I'm trying to make this enhancement as simple as possible. The count-and-then-cursor method would not only be incompatible with DB2, Oracle and whatever, but would probably take an order of magnitude more time to roll into the system than something which simply caches the result sets.
Question 3: Does anyone know of an independent group, which might have implemented cursor-based ResultSet scrolling into Postgres' JDBC driver? This would be a big time saver, as the lack of this in their driver makes the database nearly useless for any sizable system, and 'unfortunately' our company has a heavily Open-Source philosophy (believe me, I love OS too, but in this case it's crippling us.)
Question 4: Does anyone know of a company in the Sydney region who is looking to recruit a guy who knows a hell of a lot about Jabber and various IM protocols, but not so much about databases? [Disclaimer: if you are my current employer, this is a JOKE.]
Since this is such a weight on my shoulders at the moment, I'll put up a fairly sizable number of dukes. Let's hope we attract the hot-shots. These problems must have been done 1000 times before, but I've never seen a tutorial on them, and not even the 5kg JDBC book we have here helps at all.

Answer 1

To have scrollable ResultSet you can use CachedRowSet (you can use it with any DBMS):
http://developer.java.sun.com/developer/earlyAccess/crs/
To prevent OutOfMemoryError you can:
PreparedStatement ps = /* insert code here ;-) */
PreparedStatement.setMaxRows(int�maxRows);
ResultSet rs = ps.executeQuery();
CachedRowSet crs = new CachedRowSet();
crs.populate(rs);
crs.afterLast();
int numRows = crs.getRow();
crs.beforeFirst();
and if numRows = maxRows promt users that there are more records and let them redefine query
or if you don't have to display all rows (who needs 100000 rows once anyway? ;)
retrieve and cache just keys and display result page by page (there are some other paterns to do paging).
100000 records is a lot, but it depends on number of users and RAM - it's still can be done.
there is another OpenSource JDBC driver for PostgreSQL: jxDBCon http://sourceforge.net/projects/jxdbcon/
you can compare it with PostgreSQL driver