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.


-- 
Dave Page
pgAdmin: https://www.pgadmin.org
PostgreSQL: https://www.postgresql.org
EDB: https://www.enterprisedb.com

Reply via email to