Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5bFf-0007qV-Dq for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Sep 2018 18:43:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1g5bFd-0008Ff-ND for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Sep 2018 18:43:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5bFb-0008FN-Po for pgsql-hackers@lists.postgresql.org; Thu, 27 Sep 2018 18:43:01 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1g5bFW-00056G-6C for pgsql-hackers@postgresql.org; Thu, 27 Sep 2018 18:42:59 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B750021E56; Thu, 27 Sep 2018 14:42:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 27 Sep 2018 14:42:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=lhKtFUySjLrA+d3muAQUTTdGfK5TVjB5ZIcHdVj0xvw=; b=AUpJVECY 8wQmUUqGvU5jeXWDPNj1RQ7DybCUgoF6QbwIFYioaxuhIVt3A4f/vI+Uu4UadyON cWgGZVA0rxEplT+jXJCZAWSPUWpifLROBbO3BJGJD6TtG68mIHmHDEpAFmGqI4Ot b+Lj85yICmmBBg1ynqpN//f2b8DSAJv2sz/J+ELQqsOqQn6gV0o0h/TjrWEetMH9 WR8/WldFaHg1+X5yf3lucvDFBIqQv35WjDSOqWF+HkIUQFqhwNZxDjykSec2I8RP jY6089H0HIqlw0O8w9uQhoVJ0bZCyA9NhrPaO9s9W85galL5L6FHgLrW9jeQfCsd t/c30GaIyayBgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=lhKtFUySjLrA+d3muAQUTTdGfK5TV jB5ZIcHdVj0xvw=; b=nJPPEb6G1aEc+Qn0UomlaZtUn5hJOzZIimweVQgoWyK9O kv4+1z0L5uZ4VZSbLMNUuwBt5pnUkXoBkFvjh4lMbiM4qYs6XVaN18sM0Dsljh1o PEuk5HrzgG7rt1/hiB/BCQg/hLaqr0kSywBu4KuIf1KwHBu5nq5+HqWBBDbANvLq Bih7VC/6samwE7XMapfu/zae0GAR9oe3lYQ8Zu5MNDcoWB+Q+TSbJDHidrpDzJ73 Ystxd8vSt43dQde1zLp50wJyG0Cn3xhV5sjPCU68Qhob8KHdT4Q+OoaLCY3dxW4j GcNeQaLhn7KuUROCvXNrfbNTnXDc0iHzWaCdUGGIg== X-ME-Proxy: X-ME-Sender: Received: from intern.anarazel.de (c-98-210-140-171.hsd1.ca.comcast.net [98.210.140.171]) by mail.messagingengine.com (Postfix) with ESMTPA id 630A2102DD; Thu, 27 Sep 2018 14:42:51 -0400 (EDT) Date: Thu, 27 Sep 2018 11:42:49 -0700 From: Andres Freund To: Michael Paquier Cc: Postgres hackers Subject: Re: pgsql: Remove absolete function TupleDescGetSlot(). Message-ID: <20180927184249.6mta5k6fk6ul2gjq@alap3.anarazel.de> References: <20180926000413.GC1659@paquier.xyz> <20180926001038.fh7rrhrqrwvpu43t@alap3.anarazel.de> <20180926013851.GG1659@paquier.xyz> <20180926014251.zrn27ljtqlqjzswx@alap3.anarazel.de> <20180926034138.GI1659@paquier.xyz> <20180926193525.7nbw6tnb35xcgtm4@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180926193525.7nbw6tnb35xcgtm4@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2018-09-26 12:35:25 -0700, Andres Freund wrote: > Hi, > > On 2018-09-26 12:41:38 +0900, Michael Paquier wrote: > > On Tue, Sep 25, 2018 at 06:42:51PM -0700, Andres Freund wrote: > > > My point is that FuncCallContext->slot isn't actually all that related > > > to TupleDescGetSlot() and could be used entirely independently. > > > > That's fair. Why not just replacing the existing comment with something > > like "slot can be used in your own context to store tuple values, > > useful in the context of user-defined SRFs"? Just my 2c. > > I've tried to do search for users of FuncCallContext->slot and couldn't > find anything. Therefore I'm more inclined to drop it too - just about > all cases where it's useful seem to require a more extensive > datastructure around anyway. Unless somebody protests I'm going to that > in a few - if somebody later in the cycle signals a need for it, we can > still revert that part. Done so now. Greetings, Andres Freund