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 1tv4xl-00H3gg-HV for pgsql-bugs@arkaria.postgresql.org; Thu, 20 Mar 2025 01:44:49 +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 1tv4xj-00F90n-W5 for pgsql-bugs@arkaria.postgresql.org; Thu, 20 Mar 2025 01:44:48 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tv4xj-00F90f-Nc for pgsql-bugs@lists.postgresql.org; Thu, 20 Mar 2025 01:44:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tv4xh-0002LT-36 for pgsql-bugs@lists.postgresql.org; Thu, 20 Mar 2025 01:44:46 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 52K1ihsR900146; Wed, 19 Mar 2025 21:44:43 -0400 From: Tom Lane To: "=?utf-8?B?6LCt5b+g5rab?=" cc: "=?utf-8?B?RGF2aWQgRy4gSm9obnN0b24=?=" , "=?utf-8?B?cGdzcWwtYnVncw==?=" Subject: =?UTF-8?Q?Re:_=E5=9B=9E=E5=A4=8D=EF=BC=9ARe:_The_!=3D_and_+/-_sig?= =?UTF-8?Q?ns_are_joined_together_as_an_operator?= In-reply-to: References: Comments: In-reply-to "=?utf-8?B?6LCt5b+g5rab?=" message dated "Thu, 20 Mar 2025 09:11:33 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <900144.1742435083.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Mar 2025 21:44:43 -0400 Message-ID: <900145.1742435083@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "=3D?utf-8?B?6LCt5b+g5rab?=3D" writes: > But "!=3D" is not the same as "<>" > 1!=3D-1, "!=3D-" as a whole is treated as an operator, not as an operat= or "!=3D" -1, but in 1<>-1, it is treated as "<>" -1 instead of "<>-" as a= whole is treated as an operator > I think "!=3D" and "<>" should be treated in the same way [ shrug... ] It's not going to happen. The PG project's position, as stated in the docs I pointed you to, is that you should write a space between adjacent operators. The SQL spec thinks differently, so we've made sure that you can leave out space between operators that are defined in the SQL standard, but that's as far as we'll go. There are too many existing operators, both within PG core and elsewhere, that would be broken by changing those rules now. regards, tom lane