Date: Fri, 25 Mar 2022 10:42:14 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Japin Li <japinli@hotmail.com>
Cc: Michael Paquier <michael@paquier.xyz>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: turn fastgetattr and heap_getattr to inline functions
Message-ID: <202203250942.4vbvvbtkf6fq@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <ME3P282MB1667663F3D30DBCFC984E85DB6199@ME3P282MB1667.AUSP282.PROD.OUTLOOK.COM>
Archived-At: 
 <https://www.postgresql.org/message-id/202203250942.4vbvvbtkf6fq%40alvherre.pgsql>
Precedence: bulk

On 2022-Mar-24, Japin Li wrote:

> Thanks for your detail explaination.  I find bottomup_sort_and_shrink_cmp()
> has smilar code

... except that bottomup_sort_and_shrink_cmp never handles the case of
the two structs being exactly identical, so I don't think this is a
great counter-example.

> IIUC, the last statement is used to keep the compiler quiet.  However,
> it doesn't exist in LWLockAttemptLock().  Why?

What I do care about is the fact that LWLockAttemptLock does compile
silently everywhere without a final "return dummy_value" statement.  I
don't have to build a theory for why the other function has a statement
that may or may not be actually doing anything.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos.  Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)