Re: Regarding feature #6841

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Aditya Toshniwal <aditya(dot)toshniwal(at)enterprisedb(dot)com>
Cc: Anil Sahoo <anil(dot)sahoo(at)enterprisedb(dot)com>, pgadmin-hackers(at)postgresql(dot)org
Subject: Re: Regarding feature #6841
Date: 2024-04-19 13:35:43
Message-ID: CA+OCxozJpVhOTkPMv3_+EoEto+v+EeL=p1-dxjHFEvJM1EMBEQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Hi

On Fri, 19 Apr 2024 at 14:32, Aditya Toshniwal <
aditya(dot)toshniwal(at)enterprisedb(dot)com> wrote:

> Hi Dave,
>
> On Fri, Apr 19, 2024 at 6:22 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>> Hi
>>
>> On Fri, 19 Apr 2024 at 11:56, Aditya Toshniwal <
>> aditya(dot)toshniwal(at)enterprisedb(dot)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....

>
>>
>>
>>>
>>>> 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.

>
>> BTW, if we do figure out a way of doing this that we all agree is safe,
>> I'm going to want to see a bunch of automated tests against valid EPAS and
>> PG queries, as weird and bizarre as we can think of.
>>
> I agree.
>
>>
>> --
>> Dave Page
>> pgAdmin: https://www.pgadmin.org
>> PostgreSQL: https://www.postgresql.org
>> EDB: https://www.enterprisedb.com
>>
>>
>
> --
> Thanks,
> Aditya Toshniwal
> pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com*
> <https://www.enterprisedb.com/>
> "Don't Complain about Heat, Plant a TREE"
>

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

In response to

Responses

Browse pgadmin-hackers by date

  From Date Subject
Next Message Aditya Toshniwal 2024-04-19 13:45:05 Re: Regarding feature #6841
Previous Message Aditya Toshniwal 2024-04-19 13:32:06 Re: Regarding feature #6841