Kalle Hallivuori wrote:
> Actually, I'm still wondering how to do this. We need to
> 1. submit the SELECT to server so that it produces a CURSOR instead of
> a result set,
> 2. fetch and view rows from CURSOR instead of a ready-made result set,
> 3. handle a new state where a query is running but passive in a way
> which enables more interaction than just stopping the current query.
> Maybe we can call this state "active".
> I'm reading the code but I'm still not crystal clear on where and how
> to make those changes. That is where I'm welcoming input. Maybe there
> are some classes, methods or properties that you could point me to? If
> you've considered it yourself, which parts of code have you thought
> you would change, and how?
I haven't looked at it in that much detail for a number of years
unfortunately. However, from the top of my head, I would start by
looking at ctlSQLResult::Execute/pgQueryThread::execute in which you can
create the cursor and retrieve the first batch of results. Then, look at
extending pgSet such that when run with a cursor, an attempt to access a
row that hasn't be retrieved yet results in the dataset being extended
before the value is returned. Currently pgSet is tied to a single
PGResult, but I guess in cursor mode we would probably need to make that
a list of PGResults each containing <= N rows where N is a configurable
It shouldn't be too hard to tie this low level stuff in with the UI
because the grid control will automatically request data as it renders
Like I said though, this is largely off the top of my head, so I may
have missed a showstopper somewhere :-). Feel free to ping more
questions or ideas to the list for discussion though.
In response to
pgadmin-hackers by date
|Next:||From: Guillaume Lelarge||Date: 2007-12-11 23:20:56|
|Subject: Foreign key dialog|
|Previous:||From: Roberts, Jon||Date: 2007-12-11 18:44:36|
|Subject: pgAgent sessions|