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 1n5H6K-0004xG-8M for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 00:57:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n5H6I-000560-SJ for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Jan 2022 00:57:54 +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 1n5H6I-00055q-Eh for pgsql-hackers@lists.postgresql.org; Thu, 06 Jan 2022 00:57:54 +0000 Received: from mail-io1-xd34.google.com ([2607:f8b0:4864:20::d34]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n5H6F-0005xB-Hk for pgsql-hackers@postgresql.org; Thu, 06 Jan 2022 00:57:53 +0000 Received: by mail-io1-xd34.google.com with SMTP id 19so1236848ioz.4 for ; Wed, 05 Jan 2022 16:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DrkSQu40kKUs5bvdLkO4Wv34o/Ys9wpM1cnf4EVHX3Q=; b=XJz2GchC+4SpdGIits1H3rjYVvO2OuEvk3gCEfRW6t6OGcq0ESPcS8EU26X/aPW3ik 1Oh65UYbEs2HJ1thMjOv/B2Rh3ijdDiAZJO6KikJMsci3Q85/G1uHXwXpM0KqnehUsmE uLaCk09Vo+h+qXrlw8G0UrHXXX/NVv0nfyKtP7OEtEJF9ot4IzcuofvtB5Sw2qDRy6hs zgWEoKcTYyMMTpmvi0B+Io6hABC8tOTF+YNdrBuMRF4zNNWRidRKZLdTOJRtnGRrCjLc qL2XW+nCa8JWXvGZOi4qyEIAs7UbGq5il0mzFCr85dJoQ3oLmBAqbnwt5A6anm/19J7U ykRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DrkSQu40kKUs5bvdLkO4Wv34o/Ys9wpM1cnf4EVHX3Q=; b=hOBN/3L1qPuu7gaLXqxZTBvxo6lHVrV4pQvXVKGI2xDJBNl1IXJXVtK87u3SIsw+8+ wfwYqiRkcacoVS0wCQyVMsQZCKQh3DuSQYzsmqRl7GyCb1m5ByA3VAPln0dd0hA7Vrx1 WDJu2sboF8pmke/pjxO+DO3VcVTE3GKxnOwn+kHUC1nJFbSquCl+b7tgPuGVhJw+fkmy YAcN2shPVoUhvm5nxqKBzazDwuKqwIapZ9FkAE6HU7X6bMxtpfTiCurgLV+/E8M0Dbwx Yk2hzJY3jD58uBxgMILxul7sTY0Z2f2qo5n6cmCj6ilmC/qDwq3TF6Yc4tU5q5OkoSXB pGzA== X-Gm-Message-State: AOAM530L9+sHdajGyFE/2dRH024w/zNOW5a13z7O9iFnFJYBLUTHokT0 njJpejp8LTmy7DdvV0mdEfkSWg== X-Google-Smtp-Source: ABdhPJzDHz7gcV+h/7/09EBW2Pe33OAMAHgRs+V8aDcr4gPEvRD/ijREkK0RxxQk4j5cpRV9Ce+4AA== X-Received: by 2002:a02:cdd9:: with SMTP id m25mr26945988jap.110.1641430670763; Wed, 05 Jan 2022 16:57:50 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id s14sm254439iln.68.2022.01.05.16.57.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jan 2022 16:57:50 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 02CA3800AA7; Wed, 5 Jan 2022 18:57:48 -0600 (CST) Date: Wed, 5 Jan 2022 18:57:48 -0600 From: Justin Pryzby To: Melanie Plageman Cc: pgsql-hackers@postgresql.org, Andres Freund , Alvaro Herrera Subject: Re: make tuplestore helper function Message-ID: <20220106005748.GT14051@telsasoft.com> References: <20211102202353.GG17618@telsasoft.com> <20211108201338.GU17618@telsasoft.com> <20211118182430.GO17618@telsasoft.com> <20211217200419.GQ17618@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 05, 2022 at 12:09:16PM -0500, Melanie Plageman wrote: > On Fri, Dec 17, 2021 at 3:04 PM Justin Pryzby wrote: > > The rest of these are questions more than comments, and I'm not necessarily > > suggesting to change the patch: > > > > This isn't new in your patch, but for me, it's more clear if the callers have a > > separate boolean for randomAccess, rather than having the long expression in > > the function call: > > > > + tupstore = MakeFuncResultTuplestore(fcinfo, NULL, > > + rsinfo->allowedModes & SFRM_Materialize_Random); > > > > vs > > > > randomAccess = (rsinfo->allowedModes & SFRM_Materialize_Random) != 0; > > - tupstore = tuplestore_begin_heap(randomAccess, false, work_mem); > > + tupstore = MakeFuncResultTuplestore(fcinfo, NULL, randomAccess); > > > > One could also argue for passing rsinfo->allowedModes, instead of > > (rsinfo->allowedModes & SFRM_Materialize_Random). > > I've changed the patch to have MakeFuncResultTuplestore() check > rsinfo->allowedModes and pass in the resulting boolean to > tuplestore_begin_heap(). Because I modified the > MakeFuncResultTuplestore() function signature to accommodate this, I had > to collapse the two patches into one, as I couldn't maintain the call > sites which passed in a constant. > > There's a couples places that you're checking expectedDesc where it wasn't > > being checked before. Is that some kind of live bug ? > > pg_config() text_to_table() > > Yes, expectedDesc was accessed in these locations without checking that > it is not NULL. Should that be a separate patch? I don't know. The patch is already easy to review, since it's mostly limited to removing code and fixing inconsistencies (NULL check) and possible inefficiencies (randomAccess). If the expectedDesc NULL check were an 0001 patch, then 0002 (the main patch) would be even easier to review. Only foreign.c is different. > > You removed one call to tuplestore_donestoring(), but not the others. > > I guess you could remove them all (optionally as a separate patch). > > I removed it in that one location because I wanted to get rid of the > local variable it used. What local variable ? I see now that logicalfuncs.c never had a local variable called tupstore. I'm sure it was intended since 2014 (b89e15105) to say tupestore_donestoring(p->tupstore). But donestoring(typo) causes no error, since the define is a NOP. src/include/utils/tuplestore.h:#define tuplestore_donestoring(state) ((void) 0) > I am fine with removing the other occurrences, > but I thought there might be some reason why instead of removing it, > they made it into a no-op. I assume Tom left it (actually, added it back in dd04e958c) to avoid breaking extensions for no reason. And maybe to preserve the possbility of at some point in the future doing something again during the "done" step. I'd leave it for input from a committer about those: - remove tuplestore_donestoring() calls ? - split expectedDesc NULL check to an 0001 patch ? - anything other opened questions ? I'm marking this as RFC, with the caveat that the newline before MakeFuncResultTuplestore went missing again :) -- Justin