Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1jCOTF-0003lb-9M for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 14:05:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1jCOTD-0000lD-E4 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Mar 2020 14:05:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1jCOTC-0000ht-EG for pgsql-hackers@lists.postgresql.org; Thu, 12 Mar 2020 14:05:54 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jCOTA-0006oK-9w for pgsql-hackers@postgresql.org; Thu, 12 Mar 2020 14:05:53 +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 02CE5ccY020926; Thu, 12 Mar 2020 10:05:38 -0400 From: Tom Lane To: Alvaro Herrera cc: Justin Pryzby , pgsql-hackers@postgresql.org, Fabien COELHO , David Steele , "Bossart, Nathan" , Thomas Munro Subject: Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction In-reply-to: <20200312124917.GA8369@alvherre.pgsql> References: <20200312124917.GA8369@alvherre.pgsql> Comments: In-reply-to Alvaro Herrera message dated "Thu, 12 Mar 2020 09:49:17 -0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <20924.1584021938.1@sss.pgh.pa.us> Date: Thu, 12 Mar 2020 10:05:38 -0400 Message-ID: <20925.1584021938@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Alvaro Herrera writes: > I wonder if this isn't saying that the whole value-per-call protocol is > bogus, in that it seems impossible to write a useful function with it. Only if you have a *very* narrow definition of "useful function". If you look through SRF_RETURN_DONE callers, only a small minority are trying to do resource cleanup beforehand. > Maybe we should add one final call with a special flag "function > shutdown" or something, so that these resources can be released if the > SRF isn't run to completion? We already have an appropriate mechanism for cleaning up resources, ie RegisterExprContextCallback. I do not think what you're suggesting could be made to work without an incompatible break in the API for SRFs, so it's not an improvement over telling people more forcefully about how to do resource cleanup correctly. regards, tom lane