On Tue, Mar 7, 2017 at 8:07 PM, Shirley Wang <sw...@pivotal.io> wrote: > > > On Tue, Mar 7, 2017 at 4:01 AM Dave Page <dp...@pgadmin.org> wrote: >> >> On Mon, Mar 6, 2017 at 9:19 PM, Shirley Wang <sw...@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 -- Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgadmin-hackers
