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.89) (envelope-from ) id 1i84ZT-0006zq-Bg for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2019 15:30:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i84ZR-00022m-12 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Sep 2019 15:30:13 +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 1i84ZP-0000Rp-Lm for pgsql-hackers@lists.postgresql.org; Wed, 11 Sep 2019 15:30:12 +0000 Received: from wnew2-smtp.messagingengine.com ([64.147.123.27]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1i84ZI-0001rA-P0 for pgsql-hackers@postgresql.org; Wed, 11 Sep 2019 15:30:10 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id 6217F6DE; Wed, 11 Sep 2019 11:30:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 11 Sep 2019 11:30:03 -0400 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:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=UYIfJbJwITp/nveHof1vOwOdcCgNyN6Sjdqdjtqe8xM=; b=yyWnXMxm MnMidlCKF3ZqdywousHyfM3TbCKaR3D0RkyKRxLO9WUKzHMJ3zTe7M1NlBWQ5mct 1o7W2MGx4OaOmzdCWFaEgnoLUrYes2OcIgzunHg6b/+lEK44jZnA/ZSPiitYgGH7 gxhMswlz/AvR9Nv2YJZ8E6DS6wg1oRNmvGcRr7ROJ6LpZDrvh6FOrKj2PVviyA9u dys4cYqWoVhr0p95P0rehWNcZVC9yN4unzSNrgktRv05VJwGmtx7AiHfFaJG+DRW JrBzshV3o9yqu2lawOKGPpcE4CnKU3bb3tw51+HbGDV28BvRTS5YbYU3BneITmJj rvECuGe5NkIBMw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtdefgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenfg hrlhcuvffnffculddvfedmnecujfgurhepfffhvffukfggtggugfgjfgesthekredttder udenucfhrhhomheptehlvhgrrhhoucfjvghrrhgvrhgruchfrhhomhcuvdhnugfsuhgrug hrrghnthcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqeenucffohhm rghinhepvdhnughquhgrughrrghnthdrtghomhenucfkphepudeltddruddvuddrvdelrd efnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdq ihhprdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from nimloth.alvh.no-ip.org (unknown [190.121.29.3]) by mail.messagingengine.com (Postfix) with ESMTPA id 86D81D6005F; Wed, 11 Sep 2019 11:30:00 -0400 (EDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 8475F12099C; Wed, 11 Sep 2019 12:29:57 -0300 (-03) Date: Wed, 11 Sep 2019 12:29:57 -0300 From: Alvaro Herrera from 2ndQuadrant To: Masahiko Sawada Cc: Michael Paquier , Amit Kapila , Craig Ringer , Ashutosh Sharma , Julien Rouhaud , Peter Geoghegan , PostgreSQL Hackers , Abhijit Menon-Sen , Peter Eisentraut , Pavan Deolasee Subject: Re: [HACKERS] [PATCH] pageinspect function to decode infomasks Message-ID: <20190911152957.GA24327@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-11, Masahiko Sawada wrote: > On Wed, Sep 11, 2019 at 1:46 PM Michael Paquier wrote: > > > > On Tue, Sep 10, 2019 at 08:29:43AM +0530, Amit Kapila wrote: > > > Good thought, but I think even if we want to change the name of > > > tuple_data_split, it might be better done separately. > > > > Yes, that's not the problem of this patch. Not sure if it actually > > makes sense either to change it. > > Hmm it will be more consistent with other functions but I think we > would need to increase the pageinspect version to 1.8 and need the new > sql file to rename the function name. And it will be for PG12, not > PG13. If we have to do it someday I think it's better to do it in PG12 > that the table AM has been introduced to. Anyway I've attached > separate patch for it. I'd rather not change the name of the existing function ... that function is pretty old (it was introduced in 9.6, commit d6061f83a166). I think we can regard that name as an historical accident, and use a modern name convention for the new function (and any hypothetical future ones) that will, sadly, collide with the historical name for the old function. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services