Re: Query tool results in grid - Mailing list pgadmin-hackers
From | Dave Page |
---|---|
Subject | Re: Query tool results in grid |
Date | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E40103E257@ratbert.vale-housing.co.uk Whole thread Raw |
In response to | Query tool results in grid (edigeronimo@picoip.com) |
Responses |
Re: Query tool results in grid
|
List | pgadmin-hackers |
> -----Original Message----- > From: Edward Di Geronimo Jr. [mailto:edigeronimo@xtracards.com] > Sent: 21 February 2006 03:03 > To: Andreas Pflug > Cc: Dave Page; pgadmin-hackers@postgresql.org > Subject: Re: [pgadmin-hackers] Query tool results in grid > > >> This problem is partly alleviated by handing the double > timing display, > > Not really. This is *the* major issue on the query tool. Huh? I said speed is the problem, for which the timer partly helps by seperating the query/transfer time from the display time. What are you saying is the problem? > I strongly disagree. The speed certainly isn't great, but it > is managable. > Using a list instead of a grid is an issue that severely limits the > usefulness of the tool. It's fine when I'm doing development work, but > it's horrible for when someone steps into my office and asks me for a > random piece of data. > > I do understand the speed issue though. I guess the speed > issue would piss > off the new users, and scare some of them off before they > understand the > problem. Whereas the clipboard issue just pisses off the people who've > already decided to use Postgres. Agreed. There is no reason with a little work why both goals cannot be met. > > We're here at the edge of an older discussion. I'm against pushing > > ctlSqlResult to do everything, while sacrificing other basics (as > > peripheral as speed :-) I do see the need for a sophisticated data > > manipulation tool, but to me that's finally not pgAdmin but an > > additional tool. to speak M$, you wouldn't use MSAccess to fire > > arbitrary queries, but use ISQLW, and use MSAccess for data > manipulation. Yes, this is an old discussion. pgAdmin has *always*, since the very first version aimed to provide data manipulation as well as querying capabilities. > I've never worked with Access, so I can't really comment, but my > impression of Access was that it was nothing like pgAdmin. > pgAdmin is a > cross of SQL Server's Enterprise Manager and Query Analyzer. > pgAdmin does > just about everything Query Analyzer does. The only > significant difference > between the two is the horrible clipboard support for query results in > pgAdmin. Agreed. Query Analyser does manage to do both quite well and is a good benchmark to aim for IMNSHO. > > You might try to enhance the View Data tool's clipboard facilities. > > I already did that a few weeks ago. This work is largely > based on that. > The usefulness of it is limited though compared to having the > functionality in the Query Tool. > > > Please *dont* try to handle data retrieval different from what it is > > now. We do have the problem of long GUI updates, but we also have > > consistent behaviour on the libpq side, making it > comparable to psql and > > so forth. This must remain guaranteed, so any cursor > implementation is > > nonacceptable. > > I assumed Dave meant to retrieve all the data into pgAdmin, > store it in a > custom table object, and then only insert it into the grid control as > necessary. That sounds to me like it would satisfy everyone's > concerns. Yes, I did, which is pretty much what I believe Andreas has also suggested in the past. *How* that is implemented is another issue. I suspect that Andreas means he wants it encapsulated into ctlSqlResult, overriding the existing data population methods, rather than an extra layer of complexity between the data retreival code and ctlSqlResult. Regards, Dave.
pgadmin-hackers by date: