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 1lqfnp-0004e8-4X for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Jun 2021 17:46:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lqfnm-0001SH-FZ for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Jun 2021 17:46:10 +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 1lqfnm-0001S7-7R for pgsql-hackers@lists.postgresql.org; Tue, 08 Jun 2021 17:46:10 +0000 Received: from forward1-smtp.messagingengine.com ([66.111.4.223]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lqfne-00031Q-R5 for pgsql-hackers@postgresql.org; Tue, 08 Jun 2021 17:46:09 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.nyi.internal (Postfix) with ESMTP id 72E5B1940A9D; Tue, 8 Jun 2021 13:46:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Jun 2021 13:46:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=he8Bh+BKMLBaBgvcmLFzyvQcvKE455SYoIcCPSjtT do=; b=d/tez5tAcBqyA1TqHkbP8p1yHytNpiFIc2V4NVRsc34qPTljkiM0gaFoA orEJB1CMLGpChHLK/NUO812/R7s7eKsRN/ly6jvv9Js1tIZlPbOPrMffdQgxNOX6 CW4epQZXE8aURu64TjONbK1OODCHCxQIETXe1hVBf/+dFUKeMj8OHZlzH7gnLJkb 9uTj1Tmd3eGDgd+Io49ANY8B0GFdKDc7DgK4yFzu3dAAJk0EVKo9Nt2CCav3z2IK Rc153kFVGJj26MfE6e08bTNElEKD5t7L7hF6Q/he8DNIRdg5l4FGXaS4Q6+WOSbj FhP32v7EzFZCJOM1BEKhzdP61XHmg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfedtledguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ejredttdefjeenucfhrhhomheprfgvthgvrhcugfhishgvnhhtrhgruhhtuceophgvthgv rhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomheqnecuggftrf grthhtvghrnhepleevheehueeiudeiteeitdekueetleefteejffeiffdugedvffdvffdt iedvueeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epphgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Jun 2021 13:45:59 -0400 (EDT) Subject: Re: automatically generating node support functions To: David Rowley Cc: pgsql-hackers References: From: Peter Eisentraut Message-ID: Date: Tue, 8 Jun 2021 19:45:58 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 08.06.21 15:40, David Rowley wrote: > It's almost 2 years ago now, but I'm wondering if you saw what Andres > proposed in [1]? The idea was basically to make a metadata array of > the node structs so that, instead of having to output large amounts of > .c code to do read/write/copy/equals, instead just have small > functions that loop over the elements in the array for the given > struct and perform the required operation based on the type. That project was technologically impressive, but it seemed to have significant hurdles to overcome before it can be useful. My proposal is usable and useful today. And it doesn't prevent anyone from working on a more sophisticated solution. > There were still quite a lot of unsolved problems, for example, how to > determine the length of arrays so that we know how many bytes to > compare in equal funcs. I had a quick look at what you've got and > see you've got a solution for that by looking at the last "int" field > before the array and using that. (I wonder if you'd be better to use > something more along the lines of your pg_node_attr() for that?) I considered that, but since the convention seemed to work everywhere, I left it. But it wouldn't be hard to change.