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 1l5nVt-0001mF-26 for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Jan 2021 10:29:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1l5nVr-0005fD-Vn for pgsql-hackers@arkaria.postgresql.org; Sat, 30 Jan 2021 10:29:55 +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 1l5nVr-0005f6-4I for pgsql-hackers@lists.postgresql.org; Sat, 30 Jan 2021 10:29:55 +0000 Received: from wforward2-smtp.messagingengine.com ([64.147.123.31]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l5nVn-0006ae-Ta for pgsql-hackers@postgresql.org; Sat, 30 Jan 2021 10:29:54 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailforward.west.internal (Postfix) with ESMTP id 17139C14; Sat, 30 Jan 2021 05:29:49 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 30 Jan 2021 05:29:49 -0500 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=fm1; bh=GLPfSpCrYM+oC959dhcvwT542+vsh/N5uX0TwgtJH MU=; b=rGWyZDmSEiebsuTriNqUDr44zJxpW7h6Gkh954z6wteQNmfxJ7RoSM1wv x31HI394mMvkCicmL/4Ga5zsYEWjyCeUufhEOo5v2KRavQRr+R44sPLe4N/CtaXP pB4Q6MYBcJ2RljySRLeezzwbWFDvBweZK3AzP1iv1cId6oiPYe5DFtVTqL+RmXUl ajvAe89bG1tlEZ5mcPtpLehDHWZhkajHrdKIcTwfxdFh1jHAMry/PCGfITP+Hz8y umyInHGgWRaX2zS3AASlyTaYOtlKTZeNy2ZCUpLZdCcJNBw/6P3SYkNzIqcupbnu VdpHNpUpgzj33UALtGL6P4WjkfRcw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeggddukecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtgfesthejredttdefheenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvg hrphhrihhsvggusgdrtghomheqnecuggftrfgrthhtvghrnhepffdvueeftdfggfevffdv heejkeejkeehvddvueehgefhffelvdfgffffffefjedunecukfhppeekjedrudejjedrie elrddugedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepphgvthgvrhdrvghishgvnhhtrhgruhhtsegvnhhtvghrphhrihhsvggusgdrtghomh X-ME-Proxy: Received: from april.pezone.net (p57b1458c.dip0.t-ipconnect.de [87.177.69.140]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C2C31080059; Sat, 30 Jan 2021 05:29:46 -0500 (EST) Subject: Re: SELECT INTO deprecation To: Michael Paquier References: <96dc0df3-e13a-a85d-d045-d6e2c85218da@enterprisedb.com> <20201202175836.GX16415@tamriel.snowman.net> <1672926.1606941346@sss.pgh.pa.us> <8e05fc79-abca-dd3f-4d48-8aaae9525a8f@enterprisedb.com> <1723856.1607009655@sss.pgh.pa.us> <737048bf-de51-3fd4-bbcc-89f6d2bd2c4f@enterprisedb.com> <20201215221325.GA14807@momjian.us> Cc: Bruce Momjian , Tom Lane , Stephen Frost , pgsql-hackers From: Peter Eisentraut Organization: EnterpriseDB Message-ID: Date: Sat, 30 Jan 2021 11:29:44 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 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: Precedence: bulk On 2020-12-17 02:30, Michael Paquier wrote: > On Wed, Dec 16, 2020 at 06:07:08PM +0100, Peter Eisentraut wrote: >> Right, we would very likely not add it now. But it doesn't seem to cause a >> lot of ongoing maintenance burden, so if there is a use case, it's not >> unreasonable to keep it around. I have no other motive here, I was just >> curious. > > From the point of view of the code, this would simplify the grammar > rules of SELECT, which is a good thing. And this would also simplify > some code in the rewriter where we create some CreateTableAsStmt > on-the-fly where an IntoClause is specified, but my take is that this > is not really a burden when it comes to long-term maintenance. And > the git history tells, at least it seems to me so, that this is not > manipulated much. I have committed my small documentation patch that points out compatibility with other implementations.