Re: PATCH: Limit 100 default in frmEditGrid.cpp

From: "Dave Page" <dpage(at)pgadmin(dot)org>
To: "Matteo Bertini" <matteo(at)naufraghi(dot)net>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: PATCH: Limit 100 default in frmEditGrid.cpp
Date: 2009-01-12 14:07:51
Message-ID: 937d27e10901120607h7439042bp7bcf1c57f417b7e@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

On Mon, Jan 12, 2009 at 10:50 AM, Matteo Bertini <matteo(at)naufraghi(dot)net> wrote:

> What is your use case for no limit? I use the view just for:
> 1) check/modify a few records (<< 1000)
> 2) have a look at the data in one click
> Both of this use cases are not influenced by a default limit (let's say 500,
> even 1000, but << infinity)

There are, because if you set an arbitrary default to (say) 100, then
every time I want to look at a table with 127 rows I have to run the
query twice. The only way to avoid that is to set a higher arbitrary
limit, but as we've heard numerous times in the past, different people
have different ideas about how many records they regularly view in the
tool.

>> What I would be happier with is a drop-down menu on the View Data
>> button which gave access to the different options as the context menu
>> does. The button itself would then run the last option selected from
>> the drop-down menu (exactly as the plugins button does).
>>
>
> Yes, the "promoted" option and the last-selected config are a good for me.

I think that would meet everyones needs with the least amount of pain.
Can you work up a patch?

> Yes and no, that is the only button can cause a long action without further
> user action, all the other buttons are 1) immediate 2) are showing a form
> for further config.

I think the usability benefits of being able to View Data without
having to open the window and then click another button out-weigh any
perceived inconsistency.

> Something like this? (I reconfigured pgadmin3 with --enable-debug)

Yup - just like that :-). It seems to be crashing with OpenSSL's code.
Do you see the same issue on a non-SSL connection?

/D

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Quan Zongliang 2009-01-12 14:32:09 Re: SVN Commit by dpage: r7544 - in trunk/pgadmin3: . pgadmin/frm pgadmin/include/utils pgadmin/ui
Previous Message Dave Page 2009-01-12 13:57:54 Re: PATCH: Window Function support for PostgreSQL 8.4