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

Re: Repost: Patch: view data for tables/views on

From: Ivan Nejgebauer <ian-pgahack(at)uns(dot)ns(dot)ac(dot)yu>
To: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Repost: Patch: view data for tables/views on
Date: 2004-09-23 08:33:10
Message-ID: 41528A46.60307@uns.ns.ac.yu (view raw or flat)
Thread:
Lists: pgadmin-hackers
Dave Page wrote:
> I think this is exactly when it should be enabled - such that you have
> the choice that double click can do one of the following:
> 
> - Nothing
> - Open the data view on a table/view (and nothing on other objects)
> - Open the properties dialogue.

I thought about that, too, but that would be (IMO) better achieved with 
radio buttons or a combination of a checkbox and radio buttons, and I 
didn't want to rearrange the dialog too drastically.

> I'm unconvinced about silently limiting the number of rows - that's
> bound to cause a few support emails with ppl not realising there's a
> default limit (500 seems a little low anyway - what does the maximum
> query rows default to? For that matter, is there any real need for a
> separate parameter?). In the query tool it tells the user that greater
> than X rows will be retrieved, and gives the option to cancel or go
> ahead - this seems nicer behaviour to me. 

I chose 500 for no particular reason; it could be higher, or zero (no 
limit) by default. An argument can be made for having a separate data 
view row limit -- with queries, the aim is usually to retrieve a fairly 
limited result set, and the larger set would mean that a) yes, you know 
what you're doing and want the larger set, or b) the query is erroneous 
or not specific enough, and the low query limit will warn you; with data 
view, on the other hand, you are interested in the totality of data, but 
a higher limit is there to prevent memory exhaustion and application 
trashing should you choose to view a hypothetical million-row table.

I agree that a grid with an incomplete data set could have an indicator 
of that situation and a way to retrieve the rest of the data.

> This is a new feature - it's application will be deferred until after we
> branch following release as we're currently in feature freeze.

Good, that's one thing I forgot to ask in the previous posting.

> Sorry for the negative comments - I'm trying very hard not to discourage
> you from contributing further, however I'm sure you realise that pgAdmin
> got where it is today by us considering all aspects of its usability and
> design very carefully before implementing anything.

That's fine by me -- I see pgAdmin as a very nice and useful tool, which 
is why I want to contribute to its development in the first place, and I 
realize the need for thoroughly discussing any proposed addition.

i.



In response to

pgadmin-hackers by date

Next:From: Alexander BorkowskiDate: 2004-09-23 08:36:10
Subject: Re: Compilation on Windows
Previous:From: Dave PageDate: 2004-09-23 07:26:46
Subject: Re: Repost: Patch: view data for tables/views on double click

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