On Apr 8, 2005, at 3:37 PM, Joel Fradkin wrote:
> I don't think my clients would like me to aprox as it is a count of
> their
> records. What I plan on doing assuming I can get all my other problems
> fixed
> (as mentioned I am going to try and get paid help to see if I goofed
> it up
> some where) is make the count a button, so they don't wait everytime,
> but
> can choose to wait if need be, maybe I can store the last count with a
> count
> on day for the generic search it defaults to, and just have them do a
> count
> on demand if they have a specific query. Our screens have several
> criteria
> fields in each application.
Here is an interface idea I'm working on for displaying query results
in PostgreSQL. Maybe it will work for you if your connection method
does not prevent you from using cursors. I create a cursor an then
fetch the first 1000 rows. The status display has 4 paging buttons,
something like this:
|< < rows 1 - 1000 of ? > >|
The user can hit the "next" button to get the next 1000. If less than
1000 are fetched the ? is replaced with the actual count. They can
press the "last" button to move to the end of the cursor and get the
actual count if they need it. So here the initial query should be fast,
the user can get the count if they need it, and you don't have to
re-query using limit and offset.
The problem I'm looking into now (which I just posted on the general
list) is I don't see a way to get the table and column information from
a cursor. If I fetch from a cursor, the table OID and column number
values are 0 in the row description. If I execute the same query
directly without a cursor, the row description has the correct values
for table OID and column number.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL