On Tue, Apr 23, 2024, 11:49 Dave Page <dp...@pgadmin.org> wrote: > > > On Tue, 23 Apr 2024 at 11:29, Thom Brown <t...@linux.com> wrote: > >> On Tue, Apr 23, 2024, 09:15 Dave Page <dp...@pgadmin.org> wrote: >> >>> Adding some notes below to summarise a discussion we had on this in a >>> call... >>> >>> On Mon, 22 Apr 2024 at 08:26, Aditya Toshniwal < >>> aditya.toshni...@enterprisedb.com> wrote: >>> >>>> Hi Dave, >>>> >>>> On Fri, Apr 19, 2024 at 7:15 PM Aditya Toshniwal < >>>> aditya.toshni...@enterprisedb.com> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> On Fri, Apr 19, 2024 at 7:05 PM Dave Page <dp...@pgadmin.org> wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Fri, 19 Apr 2024 at 14:32, Aditya Toshniwal < >>>>>> aditya.toshni...@enterprisedb.com> wrote: >>>>>> >>>>>>> Hi Dave, >>>>>>> >>>>>>> On Fri, Apr 19, 2024 at 6:22 PM Dave Page <dp...@pgadmin.org> wrote: >>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> On Fri, 19 Apr 2024 at 11:56, Aditya Toshniwal < >>>>>>>> aditya.toshni...@enterprisedb.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>>> Even if you put the cursor on the "SELECT"? If so, that would >>>>>>>>>> imply the parser understands the string quoting; e.g. in this case, >>>>>>>>>> the >>>>>>>>>> Python multiline string. Presumably then it would also understand >>>>>>>>>> regular >>>>>>>>>> single and double quotes - what about (for example) a heredoc in a >>>>>>>>>> pl/sh >>>>>>>>>> function? >>>>>>>>>> >>>>>>>>> Yes, the parser understands all the aspects of a SQL query and so >>>>>>>>> it understands what type of token the cursor is based on which it >>>>>>>>> does the >>>>>>>>> syntax highlighting I believe. >>>>>>>>> >>>>>>>> >>>>>>>> Does it? Even EPAS extensions? >>>>>>>> >>>>>>> I mean only standard SQL grammar. >>>>>>> >>>>>> >>>>>> Standard SQL grammar doesn't help us much - PostgreSQL is probably >>>>>> the most standard compliant dialect there is, but if it deviates from the >>>>>> standard in a few cases, and has a ton of syntax that isn't even in the >>>>>> standard. However, I suspect you mean PostgreSQL-standard, as we are >>>>>> using >>>>>> the PostgreSQL dialect in CodeMirror. But, pgAdmin also supports EPAS.... >>>>>> >>>>> We'll have to test different scenarios to know exactly what works and >>>>> what doesn't. >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> It sounds like Thom has similar concerns, and I know him well >>>>>>>>>> enough to know he wouldn't chime in without good reason. >>>>>>>>>> >>>>>>>>> There are limitations and it won't work correctly apart from >>>>>>>>> standard SQL queries. Like I said, we're adding it as a new button >>>>>>>>> without >>>>>>>>> touching the existing working. If a user chooses to use the new >>>>>>>>> button, he >>>>>>>>> knows that pgAdmin will try to find the query on its own. This is an >>>>>>>>> optional feature. >>>>>>>>> Additionally, what we could do is when the user hits the button we >>>>>>>>> will show a warning and the user can opt for not showing it again. >>>>>>>>> >>>>>>>> >>>>>>>> Ten minutes later they will have forgotten that warning. >>>>>>>> >>>>>>>> I'm currently thinking that we should display the current query all >>>>>>>> the time somehow (though I'm not sure how, without taking up a lot of >>>>>>>> space). >>>>>>>> >>>>>>> Can't we add some kind of tooltip or popover on hover over the >>>>>>> execute query button? >>>>>>> >>>>>> >>>>>> Possibly :-). Let's try a PoC. >>>>>> >>>>> OK. I'll ask Anil to create some samples. >>>>> >>>> >>>> We gave a thought on how a person would know what the query is when >>>> using keyboard shortcuts. So we came up with another suggestion. How about >>>> a highlighter on what is the query based on cursor position? Example below. >>>> We can disable it from preferences. We still need to check how the >>>> performance will be, although we'll add debouncing. >>>> >>>> [image: image.png] >>>> >>> >>> So the plan is: >>> >>> 1) We automatically highlight the "current" query in the editor, >>> similarly to the mockup above. >>> >>> 2) We add an option to Preferences (also exposed under the Edit drop >>> down in the Query Tool) to turn off that highlighting. >>> >>> 3) When the user clicks the "Execute Query Under Cursor" button, it will >>> be executed immediately if highlighting is enabled. >>> >>> 4) If highlighting is disabled, the query to be executed will be >>> displayed in a confirmation dialog to allow the user to review before >>> execution. >>> >>> 5) The confirmation dialogue will have a "Don't show this again" option >>> for those that trust the CodeMirror parser enough. >>> >>> 6) A button above the resultset will be added to allow you to see the >>> query that was executed to generate that resultset in all cases. >>> >> >> A button above the resultset? Do you mean a tab, or an actual button? >> > > A button, alongside the ones that are already there for editing data etc. > > >> >> I guess I would like to understand the rationale for this feature. Users >> supposedly want this as described, but what is the precedent? I mean, I've >> used GUIs for other DMBS's where you select what you want to run, and it >> just runs the selection, even if it doesn't grab the whole query (e.g. >> excluding ORDER BY or WHERE predicates). >> > > Other GUIs (for PostgreSQL and other DBMSs) have this functionality, and > we've had multiple requests for it. > > >> >> The latter seems more flexible and predictable IMHO. And that way you can >> dispense with the confirmation dialogue, and there's no need for any >> additional configuration options because there's probably no need to >> disable it. >> > > You've been able to do the "Select and run" thing for years. If you select > text in the editor and hit the execute button, only the selected text is > sent to the server. If nothing is selected, the entire string is sent. This > feature will complement that for convenience, but for safety will have a > separate button/shortcut. >
Oh, I clearly don't use PgAdmin enough to know this already. I still find the proposal somewhat unintuitive, but the foot-gun safeguards that have been suggested sound like any pedal injuries will solely be the fault of the user. I would want to see it tested in a diverse range of scenarios though, which will require some imagination given what users will no doubt try to use it on. Regards Thom >
