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 1rxniy-00ByWy-Mt for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 12:52:16 +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 1rxniw-002BoG-RN for pgadmin-hackers@arkaria.postgresql.org; Fri, 19 Apr 2024 12:52:14 +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 1rxniw-002Bo8-J8 for pgadmin-hackers@lists.postgresql.org; Fri, 19 Apr 2024 12:52:14 +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 1rxnit-001oc2-BD for pgadmin-hackers@postgresql.org; Fri, 19 Apr 2024 12:52:13 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2dcc8d10d39so8760361fa.3 for ; Fri, 19 Apr 2024 05:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; t=1713531129; x=1714135929; 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=qEpii1gJJWvg4rOUucdOjihkQ+nbP5zDg4hrSIZhldI=; b=BqdBw5M3kVM8nduxGkJE4YUGpw1Pix4Qmg4X76AcGZrxMREnbMI4xZT0I1C4mjvp4/ ifPToJOd8/KvySoZItwXNeHH8AsBrb9yR2Wnk1hi6OYkHvyRG2wQf0UJllcq6KntnJW4 He8G4c+qR4nBKXk1B/DPoIzhGWOun9aX/7Glgo8P8S0fvqjCsSKXL/k3UI135LjhA54c JFK0nLeERkcebb2qH6UX0Jm7CZ1Ok8511B1J7cKGElO3CkkCPX/DwEt7NhuKwhI3Nmxv zdQeW7afU6BBxWRvzW+wTyK991+QGW5qfonxfRbZrXvROIlBPBfrUIvZ1zLVlqKwPcke bghA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713531129; x=1714135929; 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=qEpii1gJJWvg4rOUucdOjihkQ+nbP5zDg4hrSIZhldI=; b=AZwZLgTKy93Wz2fiH99y66/X96SDnS2Pde9wBJxrBKEtIrS8ImRIAe665WPVqhxoEW Gee0Yra5YTT+Fo9Kp6EJu6asikgDwp8Eika5+vLcDEk3EKBfm1YZBRp4y+TPC6y+MeVZ ZDzgI/Tz4LX/2ODs+p2ZxygZMDk+Gtj8dTT8m/LYwV04d5CTA1WCiDOPLCCrUOKS7vU+ 5B18FOpesYlM0RzwkKAC5fpIGr2Kdi3mRAb++HEiZqO1mXD/3823G1NLKSWvNDRtFeS3 mcNAPi4paFNnTv/vfOajamtPFY7UYywN0UlLEArlB/Sz864kvG8YKGAWreEMQQgosngb 2xVQ== X-Forwarded-Encrypted: i=1; AJvYcCUVWZxyHZlGzbQdGluY3xKvZlRc5LWAFjKTZTN2jutVblG5bCmdZW0Hm88A4xDNpl+hDdG3NncR3akqjl6u7Ct4LpKq8gO4RvG8m0sSmHI= X-Gm-Message-State: AOJu0YyBGHU5IPaYV/Y7L8FqNM35qpDH+6Vh6r4h6MYZJjCdJmIIiaVv zTcc5HJzEmS7tqiGtUEdZjIEyZvn+RGGVsyonSbH+k15o60eZf3eJyhXDN7OJ6eqSjUBK7g1fwi qLw54hB5x2jJ6DeBYFS7cnNUge0K1E6xYSOky X-Google-Smtp-Source: AGHT+IGO8IDjmNEi3QjUz2BSvRuTQ2q1a7tR0f06KdriN/oL0LOlB3VpdArqYhuRRNtPmF9QCmIaU1gJJ9Rf1HnG+7g= X-Received: by 2002:a2e:9c55:0:b0:2d6:f698:7ecf with SMTP id t21-20020a2e9c55000000b002d6f6987ecfmr1341001ljj.9.1713531128927; Fri, 19 Apr 2024 05:52:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Fri, 19 Apr 2024 13:51:57 +0100 Message-ID: Subject: Re: Regarding feature #6841 To: Aditya Toshniwal Cc: Anil Sahoo , pgadmin-hackers@postgresql.org Content-Type: multipart/alternative; boundary="00000000000040794b0616728e79" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000040794b0616728e79 Content-Type: text/plain; charset="UTF-8" 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 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? > >> 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). 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. -- Dave Page pgAdmin: https://www.pgadmin.org PostgreSQL: https://www.postgresql.org EDB: https://www.enterprisedb.com --00000000000040794b0616728e79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Fri, 19 Apr 2024 at 11:56, Aditya Toshniwal <= aditya.toshniwal@enter= prisedb.com> wrote:

Even if you put the cursor on the "SELECT&= quot;? If so, that would imply the parser understands the string quoting; e= .g. in this case, the Python multiline string. Presumably then it would als= o 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 be= lieve.

Does it? Ev= en EPAS extensions?

=C2=A0
=

It sounds like Thom has s= imilar concerns, and I know him well enough to know he wouldn't chime i= n without good reason.
There are limitations= and it won't work correctly apart from standard SQL queries. Like I sa= id, we're adding it as a new button without touching the existing worki= ng. 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.
Ad= ditionally, what we 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.
<= /div>

Ten minutes later they will hav= e forgotten that warning.

I'm currently thinki= ng that we should display the current query all the time somehow (though I&= #39;m not sure how, without taking up a lot of space).

=
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 EPA= S and PG queries, as weird and bizarre as we can think of.

--
--00000000000040794b0616728e79--