Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIVt4-0003KI-I2 for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 14:27:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pIVt3-0005Ll-B9 for pgsql-hackers@arkaria.postgresql.org; Thu, 19 Jan 2023 14:27:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIVt3-0005Lc-1d for pgsql-hackers@lists.postgresql.org; Thu, 19 Jan 2023 14:27:29 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pIVsz-0003qP-Dg for pgsql-hackers@lists.postgresql.org; Thu, 19 Jan 2023 14:27:27 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 76E10581F7C; Thu, 19 Jan 2023 09:27:23 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 19 Jan 2023 09:27:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1674138443; x=1674145643; bh=U r4pU3lkNsRvyaCZg82IlYJbNYBtn+nycsFZ5WDAiTI=; b=TEemC6yYjE/NXV2Ii ydal2sqMgYxLVDw5+4NUOHkWXKGgUBgChFzfZ32iD+N2PbDyJM8If9FskmTg2XV5 3sZR32pzw1XwFNdyWcR/cQ/ut3H/n5ua0asZSJ94stTzhv7shxtxTZxboEjOIY4i 3dELLRQH154LF4xOoKPdqbQDDm8ja6Wgrr7PoEnbkP9bUd71oLeBx4LHge3lmZrv pAAjRRPjMA/t5hpJX8wLedgKRzPjltdHwu25cbyz0dDMLs8BtywJK6UIe4I8zeC9 XdHdD39/L9OhHWZfhv2YwZkwHgRingz8bPAbAdD8IofpFD4IuWBTvfXOBGB+bC+C nEMcg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddutddgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnheptefggfffvedvgfettedv geduteehtdefgeeikefgvedvleefhefffeevvdfhvddvnecuffhomhgrihhnpehtgihtrd hinhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehp vghtvghrrdgvihhsvghnthhrrghuthesvghnthgvrhhprhhishgvuggsrdgtohhm X-ME-Proxy: Feedback-ID: i131946ab:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Jan 2023 09:27:22 -0500 (EST) Message-ID: <64b62678-ca3e-36f8-f0f2-bb430493ef4d@enterprisedb.com> Date: Thu, 19 Jan 2023 15:27:20 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: ANY_VALUE aggregate Content-Language: en-US To: Vik Fearing , PostgreSQL Hackers References: <5cff866c-10a8-d2df-32cb-e9072e6b04a2@postgresfriends.org> <464ece4e-fabb-ddac-60da-897493c4476d@enterprisedb.com> <538ac95d-f12e-92b8-0e22-85b6e35fdec9@postgresfriends.org> From: Peter Eisentraut In-Reply-To: <538ac95d-f12e-92b8-0e22-85b6e35fdec9@postgresfriends.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 18.01.23 18:01, Vik Fearing wrote: > On 1/18/23 16:06, Peter Eisentraut wrote: >> On 05.12.22 21:18, Vik Fearing wrote: >>> On 12/5/22 15:57, Vik Fearing wrote: >>>> The SQL:2023 Standard defines a new aggregate named ANY_VALUE.  It >>>> returns an implementation-dependent (i.e. non-deterministic) value >>>> from the rows in its group. >>>> >>>> PFA an implementation of this aggregate. >>> >>> Here is v2 of this patch.  I had forgotten to update sql_features.txt. >> >> In your patch, the documentation says the definition is >> any_value("any") but the catalog definitions are >> any_value(anyelement).  Please sort that out. >> >> Since the transition function is declared strict, null values don't >> need to be checked. > > Thank you for the review.  Attached is a new version rebased to d540a02a72. This looks good to me now.