Re: [pgadmin-hackers] [Design Update][History] - Mailing list pgadmin-hackers

On Tue, Mar 7, 2017 at 8:07 PM, Shirley Wang <swang@pivotal.io> wrote:
>
>
> On Tue, Mar 7, 2017 at 4:01 AM Dave Page <dpage@pgadmin.org> wrote:
>>
>> On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <swang@pivotal.io> wrote:
>>>
>>> Thanks, Dave
>>>
>>>>
>>>> I disagree. I use both the Explain and Messages tabs all the time, and
>>>> rarely the History tab. You cannot easily merge the data output and EXPLAIN
>>>> tabs because they show complementary information.
>>>
>>>
>>> I see. It may be that we haven't heard about the full value of the
>>> Explain tab (it also doesn't seem to be working on my version of pgAdmin
>>> (w/Postgres, not Greenplum)). I see no problem with keeping it as is until
>>> we learn more.
>>>
>>> Here are the updated versions of History (Explain isn't included because
>>> we were working with the assumption that the tab could be combined with
>>> results, we can add it again unless we learn something new).
>>>
>>> - Users are able to click or use the arrow keys on their keyboard to
>>> navigate through the queries on the left.
>>> - List of queries is expandable
>>> - Copy all is fixed to the top right corner so it'll be present as users
>>> vertically/horizontally scroll
>>
>>
>> That makes it impossible any details from the initial grid view.
>>
>>
>>>
>>>
>>>
>>> To your points,
>>>
>>>>
>>>> The Messages tab is used to quickly show the full set of messages from
>>>> the last executed query. Having that info only on the results tab is less
>>>> useful for a number of reasons:
>>>>
>>>> - It shows the results from all queries, thus making the display more
>>>> cluttered when you're only interested in the results of the last query
>>>> (which is probably the majority of the time).
>>>>
>>> In the messages tab, it seems like when the query ran successfully, the
>>> message shows number of rows affected and total time, both which are shown
>>> with your query history. It also seems like when there is an error message,
>>> it duplicates the description and splits out line and character. We can
>>> condense that into 3 groups of info : error code, a description, and
>>> location within the query where the error was detected.
>>
>>
>> It'll also show (in the correct order) any notices or other messages
>> raised by stored functions. It's critical that these remain easy to read as
>> they're used for debugging as well as conveying non-result info to the user.
>>
>>>
>>>
>>> Immediate feedback on any errors should be displayed right after you run
>>> the query. It appears there's already a pattern for feedback w/ the green
>>> box that appears in the bottom right corner when you run a successful query.
>>> Any sort of feedback on the query run (success/fail messages) should be
>>> treated consistently. Persistent messages can live within the history.
>>>
>>>>
>>>> - It shows information above and beyond the messages, again, cluttering
>>>> the display and detracting from the message info.
>>>
>>>
>>> You're right that the error messages displays information at a higher
>>> level than query history, which can be solved by establishing hierarchy -
>>> error messages go at the top.
>>
>>
>> No, error messages need to be shown properly ordered amongst any other
>> messages. The output is intentionally sequential - if it weren't, it would
>> be useless for debugging.
>
>
> I see. We're looking into messages for storage procedures now and how that
> should be solved. Are there other types of messages we should be aware of?

No, I don't think so. They come through the standard postgres elog
mechanism which should cover other sources as well.


--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company