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 1mOJCq-0003OP-EH for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Sep 2021 12:31:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mOJCp-0003nq-B5 for pgsql-hackers@arkaria.postgresql.org; Thu, 09 Sep 2021 12:31:03 +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 1mOJCp-0003nh-3C for pgsql-hackers@lists.postgresql.org; Thu, 09 Sep 2021 12:31:03 +0000 Received: from new3-smtp.messagingengine.com ([66.111.4.229]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mOJCk-0001M4-KG for pgsql-hackers@postgresql.org; Thu, 09 Sep 2021 12:31:02 +0000 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 3F02958044E; Thu, 9 Sep 2021 08:30:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 09 Sep 2021 08:30:56 -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=CHT7LzrGCxJkMfIlrZYnB/wr1zEf1WZmxd6dnBu5B Tg=; b=h001lSe2igU2l2lLaAUfxqjNY0tirvCkqW+YqdbWrgliyY+BEtsRAtRpP 6e3OnRGkffwIjvr1y1d3iLy+20GEN7CVahClc4qMp9adQXpI3alVj8KBdh31Ei3C fdToxvQOUplUH4opfGwNZGRZXHLTxssnKINVxhAMYsvbrsHUxa06ExM8AdztLcp4 odA27QclJ/++dFKu3ckKwd30VAMMmJHx5Fi37yf8YZpZNDJDDO0eza8XLVowtety J8+5fan1ijpDdqBU0WhZo+by7oc0bjHUXRQf20rJfemJ97XZjMw9nwCbhv6R35uh qVHuZ0jd3Az9ck9CSlg1mYM7m6GfA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudefledgheefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhephfefleefueevuddvffeh jedtjeejgfelhfdtvdffheeludetudegfeeftdffffejnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhdrvghishgvnhhtrhgruhht segvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 9 Sep 2021 08:30:52 -0400 (EDT) Subject: Re: create table like: ACCESS METHOD To: Vik Fearing , Justin Pryzby , Simon Riggs Cc: Michael Paquier , pgsql-hackers@postgresql.org, Jacob Champion , Heikki Linnakangas , Ashwin Agrawal , Ashutosh Sharma , Andres Freund , Robert Haas , Amit Kapila , Alvaro Herrera References: <20201209201328.GT24052@telsasoft.com> <20201229230805.GE25152@telsasoft.com> <20210119210331.GN8560@telsasoft.com> <20210323003926.GV4203@telsasoft.com> From: Peter Eisentraut Message-ID: <8b530d40-1e85-e3b4-774f-b9cb4e2b7ca2@enterprisedb.com> Date: Thu, 9 Sep 2021 14:30:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; 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 27.08.21 12:37, Vik Fearing wrote: > It seems like this should error to me: > > CREATE ACCESS METHOD heapdup TYPE TABLE HANDLER heap_tableam_handler; > CREATE TABLE likeam1() USING heap; > CREATE TABLE likeam2() USING heapdup; > CREATE TABLE likeamlike( > LIKE likeam1 INCLUDING ACCESS METHOD, > LIKE likeam2 INCLUDING ACCESS METHOD > ); > > At the very least, the documentation should say that the last one wins. Hmm. The problem is that the LIKE clause is really a macro that expands to the column definitions of the other table. So there is, so far, no such as thing as two LIKE clauses contradicting. Whereas the access method is a table property. So I don't think this syntax is the right approach for this feature. You might think about something like CREATE TABLE t2 (...) USING (LIKE t1); At least in terms of how the syntax should be structured.