Re: Data grid: fetching/scrolling data on user demand

Hi,

> On Tue, Oct 17, 2017 at 1:44 PM, Tomek <tomek(at)apostata(dot)org> wrote:
>
>> Hi,
>>
>>>>>> It is not exactly truth... In v3 the query is executed, fetched and all rows are displayed,
>>>>>
>>>>> No they're not, though they are all transferred to the client which is why it's slower.
>>>>
>>>> They are not what?
>>>
>>> The handling of rows in pgAdmin 3 is not as you described.
>>
>> So please tell me how is it done.
>
> You can find the code here:
> https://git.postgresql.org/gitweb/?p=pgadmin3.git;a=tree;h=216f52a5135db3124268a32c553b812547d4b918;
> b=216f52a5135db3124268a32c553b812547d4b918

You are using libpq, You fetch data, You display data. I don't know how to describe it simpler...

>> Part of the data...
>> Please explain to me what is the point o requesting 100000 and getting 1000 without possibility to
>> access the rest?
>
> Of course you can get all 100000, you just scroll down. Saying that you can only get 1000 "without
> possibility to access the rest" is 100% factually incorrect.

Right I forgot to add "at least quickly" as I later did.

> No - I'm telling you what nearly 20 years of interacting with pgAdmin users has indicated they
> likely want. If it's not what you want, then you are free to look at other tools. We do our best to
> meet the requirements of the majority of our users, but it's obviously impossible to meet everyones
> requirements.
>
>> You cut out a lot of v3 features,
>
> Yes. Did you ever create an operator family? Or use the graphical query designer that crashed all
> the time? Those and many other features were intentionally removed. Some have been put back in
> cases where it became clear they were needed and others will still be added in the future - but the
> vast majority of things we left out will likely remain gone because they add complexity and
> maintenance costs for zero or near zero value.

This is old - a lot o people told You already what is missing - and not some depreciated stuff but important stuff like for example possibility to edit table data without PRIMARY key and OIDS=TRUE...

>> You purposely limit usability to account for poor performance and call it a feature...
>
> You haven't (as far as I can see) described how we limited usability, except by making claims that
> are provably wrong.

I know - almost every suggestion/problem with v4 in comparison to v3 in this list was dismissed by You, by telling us Users that we do not know what we want and the only one who do is You.

> I'm not going to spend any more of my free time on this thread. I have little enough as it is.

Of course, because I'm being paid for talking to the wall...

--
Tomek