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

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.