Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rxoPK-00C75N-31 for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 13:36:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rxoPI-002WzO-RD for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 13:36:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rxoPI-002WzG-Iv for pgadmin-hackers@lists.postgresql.org; Fri, 19 Apr 2024 13:36:00 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rxoPD-001otR-SO for pgadmin-hackers@postgresql.org; Fri, 19 Apr 2024 13:35:59 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2db2f6cb312so37939381fa.2 for ; Fri, 19 Apr 2024 06:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1713533755; x=1714138555; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=UZJ+wTsnC4xebUfvtDRYq5+pb6AlF9cOXGrtl1q3vFE=; b=gj044kdBQi90SbERqHo8MY/Qy2ySVU4bZqRBGgwoK9zMYyxyc6KOB7WMTKiys5IUqg 4Cp+D7+ohxZ2QIF5s7qV7KPIqRpIq6zJjOx9e/1lXnSBMqEoqSOkIw/AWqTO9PRHiqoX yeqP/uCxge+r089qFTE2cLQZCgh1XHUUgEyJ9/Y8WIqED12FJTy++D4JaGstwJoG6jbC J1sSC5/AIV+dIplLxuVD+dcy8ruysTj1WSWuLS63OeJp4niC3D4TqasGG8BEgIFpg/tT bFMmbjYHpedf00h1ZCPRSyEh5tmNORaoGKDO5qMD0LopGqTk0mo56ApRqhF9lKED4G8t yK1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713533755; x=1714138555; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=UZJ+wTsnC4xebUfvtDRYq5+pb6AlF9cOXGrtl1q3vFE=; b=O4S6Pm4HjTxvNX5jymwGc5oOBijaIYlFWz0zSeBQYdHSkJ/xsSu/sWHtL/qvQRgvXX xD/VCvNAWd2oXWZw47dm674zVokiqMGKfnsh/QJTpg4TDN0B1Fz2nwDGN9g/CVb7hDqw rt5VVa/+VQZpRYZBaFsi5LlVcpchdN5KnsGRcEtRWggBH7ozbSnH6AsI+AgZ7utCX9of Va/SYEuWEzQ3GndPt9zIES224JrcjP8YYrQOK6CC7AVoMJsAcHDpqEJCptU8mi42cZUR patgh15cxW27uU9Sxm7ekYegbE08bzQnbVprbf3mFQ8Q7Kz7AJXgPOPpUoXkwIQcA3NR zh6w== X-Forwarded-Encrypted: i=1; AJvYcCVAncN/kPGMP6fm4tHIeStvl20vT1nueg5IIGlsjjtqps+lPAT1XKgTuXD09SN/iYT6Ga4zEW6d/hOlwPmMCiOIlieyGxg7h2bvrvzzzvo= X-Gm-Message-State: AOJu0YwcBVzj9SmI5lJIywoJUjhFsetGtMvKBYtv5hBon+c6gCjpqK81 qhNe9bGMMVa1NNrGsjyf/UrV7kq29PWNqWcDhaCsXqNVRCkOYfHTw1nAzLugAeto3JAK+gUATUD mMCmj75UJl2IaKaQ4Im7p5pXdnMQTc9mjj7S1 X-Google-Smtp-Source: AGHT+IFXWr19frdmjZbzYHwK/2neUMaYwXd85/jpjbxTvc7T3oFva6u5OZFEDqSt0EoNNrFikClUXroy+cJSTW/DcI4= X-Received: by 2002:a05:651c:1414:b0:2da:16fd:5c9b with SMTP id u20-20020a05651c141400b002da16fd5c9bmr1684249lje.9.1713533754987; Fri, 19 Apr 2024 06:35:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 19 Apr 2024 14:35:43 +0100 Message-ID: Subject: Re: Regarding feature #6841 To: Aditya Toshniwal Cc: Anil Sahoo , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000c714e50616732a48" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c714e50616732a48 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi On Fri, 19 Apr 2024 at 14:32, Aditya Toshniwal < aditya.toshniwal@enterprisedb.com> wrote: > Hi Dave, > > On Fri, Apr 19, 2024 at 6:22=E2=80=AFPM Dave Page wro= te: > >> Hi >> >> On Fri, 19 Apr 2024 at 11:56, Aditya Toshniwal < >> aditya.toshniwal@enterprisedb.com> wrote: >> >>> >>>> Even if you put the cursor on the "SELECT"? If so, that would imply th= e >>>> parser understands the string quoting; e.g. in this case, the Python >>>> multiline string. Presumably then it would also understand regular sin= gle >>>> and double quotes - what about (for example) a heredoc in a pl/sh func= tion? >>>> >>> 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 t= o >>>> 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 touch= ing >>> 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 a= nd >> 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* > > "Don't Complain about Heat, Plant a TREE" > --=20 Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com --000000000000c714e50616732a48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Fri, 19 Apr 2024 at 14:32, Aditya Toshniwal <= aditya.toshniwal@enter= prisedb.com> wrote:
Hi=C2=A0Dave,

On Fri, Apr 19, 2024 at 6:22=E2=80=AFPM Dave Page <dpage@pgadmin.org> wrote:
Hi

On Fri, 19 Apr 2024 at 11:56, A= ditya Toshniwal <aditya.toshniwal@enterprisedb.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa= dding-left:1ex">

Even if y= ou put the cursor on the "SELECT"? If so, that would imply the pa= rser understands the string quoting; e.g. in this case, the Python multilin= e string. Presumably then it would also understand regular single and doubl= e 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 whic= h 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 t= hat isn't even in the standard. However, I suspect you mean PostgreSQL-= standard, as we are using the PostgreSQL dialect in CodeMirror. But, pgAdmi= n also supports EPAS....
=C2=A0

=C2=A0

It sounds like Thom has similar = concerns, and I know him well enough to know he wouldn't chime in witho= ut good reason.
There are limitations and it= won't work correctly apart from standard SQL queries. Like I said, we&= #39;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 fin= d the query on its own. This is an optional feature.
Additiona= lly, what we could do is when the user hits the button we will show a warni= ng and the user can opt for=C2=A0not showing it again.

Ten minutes later they will have forgo= tten that warning.

I'm currently thinking that= we should display the current query all the time somehow (though I'm n= ot sure how, without taking up a lot of space).
Can't we add some kind of toolti= p or popover on hover over the execute query button?

Possibly :-). Let's try a PoC= .
=C2=A0

BTW, if we do figure out a way of doing this that we all ag= ree is safe, I'm going to want to see a bunch of automated tests agains= t valid EPAS and PG queries, as weird and bizarre as we can think of.
=
I agree.
=

--
<= div dir=3D"ltr" class=3D"gmail_signature">


--
Thanks,
Aditya Toshniwal
pgAdmin Hacker=C2=A0| Sr. Software Architect=C2=A0| enterprisedb.com --000000000000c714e50616732a48--