Skip site navigation (1) Skip section navigation (2)

Re: Lightspeed for frmQuery and other issues.

From: "Edward Di Geronimo Jr(dot)" <edigeronimo(at)xtracards(dot)com>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Lightspeed for frmQuery and other issues.
Date: 2006-04-30 16:26:20
Message-ID: 20060430122620.dfm9klqp3cgsoo08@webmail.picoip.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
Quoting Andreas Pflug <pgadmin(at)pse-consulting(dot)de>:

> I still don't see a need for that extended handling, because the ctl
> always allowed row selections (and column selections can be achieved
> from SELECT ...., a basic SQL feature... )

Very often in my work, I would not know exactly what columns I need  
the data from until after I see the results of the query. Someone  
would walk into my office and say "What's wrong with Joe Smith's  
account?" I'd run a query to get an overview of the account, and what  
columns I needed would change depending on what looked to be wrong.  
It's a lot easier to click on the cell I need and hit copy than to run  
another query to narrowing things down.

>> Users dont care about virtual controls or not.
>
> They do. It's the speed issue, esp. on non-win32.

The implementation I did was 4x faster than the old implementation,  
which apparently had been acceptable for a long time, but also offered  
more features.  There was no tradeoff to that work, unless you had a  
phobia of grids. Now you're into trading features for speed.

>> Users care about basic  functionality like being able to copy   
>> subsets of data into the  clipboard. Only behing able to copy   
>> entire rows at a time is a half  brewn implementation. It would   
>> have been much easier for you to  refactor things into a virtual   
>> table
>
> Wrong. Look at the current implementation, which basically takes
> version 5021 and *removes* 100 lines of code.

Sticking the new data retrieval code into a virtual table still would  
have been less work than ripping out the grid and implementing a  
virtual list. Most of the code you removed was there either to  
implement the additional clipboard support your code doesn't handle,  
or to work around your earlier instance on keeping the retrieval the  
same.

> Not quite, I always insisted on doing it "the virtual way" and made
> quite clear that I'd enforce it. Explaining how to do it required more
> work than to do it, I said that earlier. See how it works now, and do
> it with wxGrid if you like.

You said this months ago when I did the initial grid patch:

> 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

You refused to clarify when asked what was and wasn't acceptable, and  
basically gave the impression that nothing could possibly satisfy you.  
So, the only thing that seemed reasonable to do was to disturb as  
little code as possible. Hence how we ended up where we're at now.

Ed

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



In response to

Responses

pgadmin-hackers by date

Next:From: Andreas PflugDate: 2006-04-30 16:44:13
Subject: Re: Lightspeed for frmQuery and other issues.
Previous:From: Andreas PflugDate: 2006-04-30 16:23:00
Subject: Re: Lightspeed for frmQuery and other issues.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group