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.96) (envelope-from ) id 1wIQ7V-0084ik-3A for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Apr 2026 12:03:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wIQ7U-007OFv-02 for pgsql-bugs@arkaria.postgresql.org; Thu, 30 Apr 2026 12:03:52 +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.96) (envelope-from ) id 1wIQ7T-007OFm-1z for pgsql-bugs@lists.postgresql.org; Thu, 30 Apr 2026 12:03:51 +0000 Received: from forwardcorp1d.mail.yandex.net ([178.154.239.200]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wIQ7N-00000003Vbx-1y3F for pgsql-bugs@lists.postgresql.org; Thu, 30 Apr 2026 12:03:50 +0000 Received: from mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net [IPv6:2a02:6b8:c42:94a9:0:640:a3fa:0]) by forwardcorp1d.mail.yandex.net (Yandex) with ESMTPS id 360BD808BA; Thu, 30 Apr 2026 15:03:42 +0300 (MSK) Received: from smtpclient.apple (unknown [2a02:6bf:8080:43b::1:1b]) by mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net (smtpcorp) with ESMTPSA id e3a6tA0LCSw0-qbCNZXeU; Thu, 30 Apr 2026 15:03:41 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1777550621; bh=2B0nVhnVpcb46viYCgup8FMnn/pLVGmeaFSe+aHiIxs=; h=Message-Id:To:Date:References:Cc:In-Reply-To:From:Subject; b=aapge40gfrLLbJML+jN2aFMi37CCUDqF3DZd0cFdMeFlk7RSeGigl0pgArpXybp2Y gAHTKZ66A7ldf+jgyJ9gUlYdHpXBz4vt4RM5XQQZO5+3HYCGYLguMxKYOcRzeLhk/r 5xW5ptby/sc/lheq/6VEOQsMxyajwXNLEIHiXuuQ= Authentication-Results: mail-nwsmtp-smtp-corp-main-68.klg.yp-c.yandex.net; dkim=pass header.i=@yandex-team.ru Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\)) Subject: Re: BUG #19458: OOM killer in jsonb_path_exists_opr (@?) with malformed JSONPath containing non-existent variables From: Andrey Borodin In-Reply-To: Date: Thu, 30 Apr 2026 17:03:29 +0500 Cc: Amit Langote , Andrey Rachitskiy , pgsql-bugs@lists.postgresql.org, dhyan@nataraj.su Content-Transfer-Encoding: quoted-printable Message-Id: <6DE4A9D6-6D5C-41C0-8AFE-F51CFBDDAD5A@yandex-team.ru> References: <19458-a69c98bc498333ba@postgresql.org> To: Nikita Malakhov X-Mailer: Apple Mail (2.3864.500.181) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 29 Apr 2026, at 01:19, Nikita Malakhov wrote: >=20 > According to the Jsonpath standard, malformed expression should return = an error, > but not all cases of malformation are thoroughly described. >=20 > When this functionality was developed (Jsonpath and SQL/JSON) the = absence > of the variable was considered as malformation and was decided to = throw an error > in threads long time ago. In case this behavior to be a subject for = change it surely > should not be backported, but the error-throwing code has to. I think you just explained very well why we throw an error. Your = arguments against silent mode are valid and we don't need to consider RETURN_ERROR any = further. Current master behavior throws an error, in this thread author propose = to backport it. This might be behavior change for some users. But it seems to me we have = to backport, because SELECT '42'::jsonb @? '$"no_such_var"'; should not return true. What do you think? Best regards, Andrey Borodin.=