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 1rxoYo-00C94d-Dl for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 13:45:50 +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 1rxoYm-002ddb-6C for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 13:45:48 +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 1rxoYl-002ddT-SF for pgadmin-hackers@lists.postgresql.org; Fri, 19 Apr 2024 13:45:47 +0000 Received: from mail-oo1-xc31.google.com ([2607:f8b0:4864:20::c31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rxoYi-001oxE-2K for pgadmin-hackers@postgresql.org; Fri, 19 Apr 2024 13:45:46 +0000 Received: by mail-oo1-xc31.google.com with SMTP id 006d021491bc7-5aa1bf6cb40so1295837eaf.1 for ; Fri, 19 Apr 2024 06:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1713534342; x=1714139142; 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=7Nb2peywSVeCYPXdNznfLcLBIkLma56yr7JDBuLP8BE=; b=W4H5So6QbdRoPJkHT4xghbSy3UxJB45m5M6e9NmOBUMTUs6zRbEkbWotbZocLDkxFh nR6JqsncXkc73Amu9DnmGVCV1otgznATjIkLYbpnj67QCoshNOioI48lIGkeaBcVYJII K7A/TdS9/Txvx5Lp0h9w1qsIWdYcQH3Yjsz2B64N9XamP2Xl/HF12SH8sYB78SWy0HAj gobLCPUC5yf0eT/T045gLDgJajFsLuUNG0As0J5qdZ1mHKZOUIkLUgjmCpWreDnFc2eN +ESUcjmYqAjcL8n0IoqveqO8ChKdOh4liHaaeJ9dHhuU4g7p2gGmJcsgFuRpEmTaHTUh rtJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713534342; x=1714139142; 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=7Nb2peywSVeCYPXdNznfLcLBIkLma56yr7JDBuLP8BE=; b=IptK/Rst0fjNNZL6xvVnQtYhihoTPZKWTeMGe/Vdw3P4DeCh84czqqQjWWAFP8xWRz cIttFG7YhDMQgea+kv+aAZaO3hFr2K20POTJjeJecgPblFqwJ5MydnRh2tIHenZwwEs9 PnnYD4tFOmVs6HzyvPw+KuZEnr0Uega07TP8/ooWY4D8H8r0BmoRIPGvx/n7++7tfo94 BT2IV6/oftc2DDHZPm6R189ebBlUfY4s9vj01z0oKWPES7hoopxaleDwVW8aCv/RT5Kn 4VIyH1wESo7QaXT6I1r0biUKfw9A4S3x48/0I9yxPoFptD3OxkGbRKuwiUgzxaIN5ssT cEdA== X-Forwarded-Encrypted: i=1; AJvYcCUO2cSDD15hnEg57UGtG96HTcHHl6vBq/wgWU8SQrZ8uHK09cskDQ9cMSMU5rknCj7PnGssMnlxGY2o3QxOkLXyZhBroUH1D8adIXJ266M= X-Gm-Message-State: AOJu0Yz7HNsVHB3UBeEM6jJ2tt0krngYWxHXDiCGPtt2nbu5eJew4D4X ZFEbEkRNxq4iLlCmk5lJ07M29YIAtgdwOjD0zLkDBJ3XeS1utxi47Rsey/QTkmSHKBF+PBrCyy2 m6C2zOwBxPDxSoY+D79/HnBa1x+HtGIhbRphC X-Google-Smtp-Source: AGHT+IGimOKoUofwwPoqhPMCSEoxmBRvQ3aRivMyhsaiQNDLeDWLd+gh1eAHgKiYAXEZVa58VEvVwNueRUvI/pgc16c= X-Received: by 2002:a4a:345:0:b0:5ac:9f37:3ef4 with SMTP id 66-20020a4a0345000000b005ac9f373ef4mr2254570ooi.4.1713534341733; Fri, 19 Apr 2024 06:45:41 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aditya Toshniwal Date: Fri, 19 Apr 2024 19:15:05 +0530 Message-ID: Subject: Re: Regarding feature #6841 To: Dave Page Cc: Anil Sahoo , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="000000000000c003620616734dc6" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c003620616734dc6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dave, On Fri, Apr 19, 2024 at 7:05=E2=80=AFPM Dave Page wrote= : > 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 wr= ote: >> >>> 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 >>>>> the parser understands the string quoting; e.g. in this case, the Pyt= hon >>>>> multiline string. Presumably then it would also understand regular si= ngle >>>>> and double quotes - what about (for example) a heredoc in a pl/sh fun= ction? >>>>> >>>> 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 th= e >>>> 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 usin= g > 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 touc= hing >>>> the existing working. If a user chooses to use the new button, he know= s >>>> that pgAdmin will try to find the query on its own. This is an optiona= l >>>> feature. >>>> Additionally, what we could do is when the user hits the button we wil= l >>>> 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. > > >> >>> 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* >> >> "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 > > --=20 Thanks, Aditya Toshniwal pgAdmin Hacker | Sr. Software Architect | *enterprisedb.com* "Don't Complain about Heat, Plant a TREE" --000000000000c003620616734dc6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Dave,

On Fri, Apr 19, 2024 at 7:0= 5=E2=80=AFPM Dave Page <dpage@pgadm= in.org> wrote:
Hi

On Fri, 19 Apr 2024 at 14:32, Aditya Toshniwa= l <aditya.toshniwal@enterprisedb.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 2= 024 at 11:56, Aditya Toshniwal <aditya.toshniwal@enterprisedb.com> wr= ote:

Eve= n 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 mu= ltiline 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 o= n 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 u= s much - PostgreSQL is probably the most standard compliant dialect there i= s, but if it deviates from the standard in a few cases, and has a ton of sy= ntax that isn't even in the standard. However, I suspect you mean Postg= reSQL-standard, as we are using the PostgreSQL dialect in CodeMirror. But, = pgAdmin also supports EPAS....
We'll hav= e to test different scenarios to know exactly what works and what doesn'= ;t.
=C2=A0

=C2=A0

It sounds like Thom has similar concerns, a= nd I know him well enough to know he wouldn't chime in without good rea= son.
There are limitations and it won't = work correctly apart from standard SQL queries. Like I said, we're addi= ng it as a new button without touching the existing working. If a user choo= ses 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 w= e could do is when the user hits the button we will show a warning and the = user can opt for=C2=A0not showing it again.

Ten minutes later they will have forgotten that w= arning.

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 popove= r on hover over the execute query button?

Possibly :-). Let's try a PoC.
OK. I'll ask Anil to create some samples.<= /div>
=C2=A0

BTW, if we do figure out a way of doing this that w= e all agree is safe, I'm going to want to see a bunch of automated test= s against valid EPAS and PG queries, as weird and bizarre as we can think o= f.
I<= span class=3D"gmail_default" style=3D"font-family:verdana,sans-serif"> agre= e.

--


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


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