Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFl56-0005Z7-Kr for pgsql-committers@arkaria.postgresql.org; Fri, 17 Nov 2017 18:09:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eFl55-0005KV-47 for pgsql-committers@arkaria.postgresql.org; Fri, 17 Nov 2017 18:09:35 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eFl54-0005KF-Q5 for pgsql-committers@lists.postgresql.org; Fri, 17 Nov 2017 18:09:34 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eFl51-0001gQ-EV for pgsql-committers@postgresql.org; Fri, 17 Nov 2017 18:09:33 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vAHI9Q69012526; Fri, 17 Nov 2017 13:09:26 -0500 From: Tom Lane To: Andres Freund cc: pgsql-committers@postgresql.org, Thomas Munro Subject: Re: pgsql: Remove BufFile's isTemp flag. In-reply-to: <20171117175811.qgrs75pgyhl42kgr@alap3.anarazel.de> References: <23339.1510887494@sss.pgh.pa.us> <20171117031149.hslkxis732hkjuog@alap3.anarazel.de> <24110.1510888651@sss.pgh.pa.us> <32216.1510935834@sss.pgh.pa.us> <20171117175811.qgrs75pgyhl42kgr@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 17 Nov 2017 09:58:11 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12524.1510942166.1@sss.pgh.pa.us> Date: Fri, 17 Nov 2017 13:09:26 -0500 Message-ID: <12525.1510942166@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andres Freund writes: > On 2017-11-17 11:23:54 -0500, Tom Lane wrote: >> Or maybe we should revert 11e264517. It doesn't seem to be buying >> much to make up for the loss of flexibility. > There's a bunch of work adding new functionality to buffile.c > pending. And having code paths that have been dead for 10+ years around > and maintaining them in working order doesn't seem like a good use of > time. OK, if there's active work going on in the area, that's a good reason to simplify. But let's get rid of all vestiges of the old non-temp semantics. regards, tom lane