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 1qKEBd-00013u-QD for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Jul 2023 08:30:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qKEBb-0002vq-A9 for pgsql-hackers@arkaria.postgresql.org; Fri, 14 Jul 2023 08:29:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qKEBb-0002vh-0Q for pgsql-hackers@lists.postgresql.org; Fri, 14 Jul 2023 08:29:59 +0000 Received: from smtp.outgoing.loopia.se ([93.188.3.37]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qKEBX-000O2B-7o for pgsql-hackers@lists.postgresql.org; Fri, 14 Jul 2023 08:29:58 +0000 Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 65F192F9D1C5 for ; Fri, 14 Jul 2023 10:29:54 +0200 (CEST) Received: from s934.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 56C792E2834F; Fri, 14 Jul 2023 10:29:54 +0200 (CEST) Received: from s473.loopia.se (unknown [172.22.191.6]) by s934.loopia.se (Postfix) with ESMTP id 551E07CEABB; Fri, 14 Jul 2023 10:29:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=6.2 tests=[ALL_TRUSTED=-1] autolearn=disabled Received: from s980.loopia.se ([172.22.191.5]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with UTF8LMTP id KmiDgFOZ4v-w; Fri, 14 Jul 2023 10:29:54 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: daniel@yesql.se X-Loopia-Originating-IP: 89.255.232.193 Received: from smtpclient.apple (customer-89-255-232-193.stosn.net [89.255.232.193]) (Authenticated sender: daniel@yesql.se) by s980.loopia.se (Postfix) with ESMTPSA id DBED12201681; Fri, 14 Jul 2023 10:29:53 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: 16beta2 SQL parser: different defaults on absent_on_null From: Daniel Gustafsson In-Reply-To: <4484ffc1-187d-613e-13d9-d3ff3f30e7f9@splendiddata.com> Date: Fri, 14 Jul 2023 10:29:53 +0200 Cc: pgsql-hackers@lists.postgresql.org Content-Transfer-Encoding: quoted-printable Message-Id: <302258BE-ADAD-4884-9C30-F6243A156376@yesql.se> References: <4484ffc1-187d-613e-13d9-d3ff3f30e7f9@splendiddata.com> To: Martin Butter X-Mailer: Apple Mail (2.3696.120.41.1.3) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 14 Jul 2023, at 07:53, Martin Butter = wrote: > While adapting a Java implementation of the SQL parser, I noticed that = in structures JsonArrayAgg, JsonArrayConstructor, = JsonArrayQueryConstructor and JsonObjectConstrutor, the absent_on_null = field defaults to TRUE. > But in JsonObjectAgg, absent_on_null defaults to FALSE. > Is that intentionally? I would say so, an empty NULL|ABSENT ON NULL clause for arrays is = defined as true, while for objects it's defined as false (which is shared between = both json_object() and json_objectagg()). -- Daniel Gustafsson