On Mon, 2006-12-11 at 11:00 +0000, Gregory Stark wrote: > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > We might be able to finesse the protocol problem by teaching EA to > > respond to query cancel by emitting the data-so-far as a NOTICE (like it > > used to do many moons ago), rather than a standard query result, then > > allowing the query to error out. However this'd be fairly unfriendly > > for client-side tools that are expecting a query result. > > What I suggested was introducing a new FE/BE message type for analyze query > plans. Then clients that recognize it can use it to display the query plan > without interfering with the query results. Clients that don't know what to do > with it would have to just ignore it. > > Then we could introduce as many ways of triggering these messages as we like. > A GUC to trigger one every n seconds, a FE/BE message like QueryCancel, say, > QueryProbe which triggers one when the user presses a button in pgadmin or C-t > (SIGINFO) in psql, etc. > > I was thinking that it should be more structured than the current block of > text that clients receive. I had in mind to make it equivalent to a PGResult > so the various bits of data would be in different named columns. This would > let GUI clients like pgadmin interpret the results more effectively and make > it easier for us to add data without worrying about information overload on > the user's side. > > And the query would keep operating. Canceling the query and statement_timeout > would both be entirely orthogonal to requesting analyze results.
I like the idea, but its more work than I really wanted to get into right now. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
