Re: Page Scan Mode in Hash Index
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>,
Jesper Pedersen <jesper.pedersen@redhat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-04T18:09:03Z
Lists: pgsql-hackers
On Fri, Aug 4, 2017 at 9:44 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > There is no need to use Parentheses around opaque. I mean there is no > problem with that, but it is redundant and makes code less readable. Amit, I'm sure you know this, but just for the benefit of anyone who doesn't: We often include these kinds of extra parentheses in macros, for good reason. Suppose you have: #define mul(x,y) x * y If the user says mul(2+3,5), it will expand to 2 + 3 * 5 = 17, which is wrong. If you instead do this: #define mul(x,y) (x) * (y) ...then mul(2+3,5) expands to (2 + 3) * (5) = 25, which is what the user of the macro is expecting to get. Outside of macro definitions, as you say, there's no point and we should avoid it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Remove lsn from HashScanPosData.
- 22c5e73562c5 11.0 landed
-
Fix trivial mistake in README.
- 79a4a665c046 11.0 landed
-
hash: Implement page-at-a-time scan.
- 7c75ef571579 11.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited