Technical Analysis: Renaming pg_attribute_always_inline to a Shorter Form

Core Problem

The macro pg_attribute_always_inline — used to force the compiler to inline a function regardless of optimization heuristics — is excessively verbose at 27 characters. This length causes practical formatting problems when combined with PostgreSQL's pgindent tool, which enforces strict column limits and line-wrapping rules. When function prototypes include this macro alongside moderately long function names and parameter lists, pgindent is forced to reflow the declaration across multiple lines in awkward ways.

This is not merely an aesthetic concern. The index prefetching patch (and other performance-critical code paths) makes significant use of forced inlining to ensure that hot-path function calls are eliminated at compile time. As more performance-sensitive code adopts this pattern, the formatting burden compounds.

Architectural Context

The pg_attribute_always_inline macro lives in PostgreSQL's portability/compiler abstraction layer (likely c.h or a related header). It serves a dual purpose:

1. On GCC/Clang: Expands to __attribute__((always_inline)) inline — note that it includes both the attribute and the inline keyword itself (since commit 434e6e148441).
2. On MSVC: Expands to __forceinline.
3. On other compilers: Falls back to plain inline.

Peter Eisentraut's observation is architecturally significant: the macro name contains _attribute_ suggesting it only wraps a GCC-style __attribute__, but in reality it bundles the inline storage-class keyword as well. This makes the current name semantically misleading — it's not just an attribute annotation, it's a complete inlining directive.

The existing precedent pg_noinline (which wraps __attribute__((noinline))) demonstrates that PostgreSQL already has shorter macro names for compiler directives that don't embed _attribute_ in their name.

Proposed Solutions

Option 1: pg_always_inline (Andres's proposal)

• Drops the _attribute_ infix
• 16 characters (saves 11 characters)
• Straightforward and self-documenting
• Still longer than pg_noinline (11 chars)

Option 2: pg_mustinline (Thomas Munro's counter-proposal)

• 13 characters (saves 14 characters)
• Consistent in style with pg_noinline — both use a short directive word after the pg_ prefix
• Even more effective at keeping prototypes within column limits
• Slightly less immediately recognizable to developers coming from other projects where "always_inline" is the standard terminology

Key Design Tradeoffs

1. Familiarity vs. brevity: always_inline is the canonical term across GCC, Clang, and Linux kernel code. Developers immediately recognize it. mustinline is novel but more consistent with PostgreSQL's own naming conventions.

2. Column-limit pressure: Even pg_always_inline may not fully solve the formatting problem for functions with verbose names and multiple parameters. pg_mustinline provides more headroom.

3. Semantic accuracy: Neither proposed name contains _attribute_, which is correct since the macro includes inline itself. Both proposals fix the naming misnomer.

Assessment

This is a low-risk, high-consensus rename. The change is mechanical (find-and-replace across the tree plus updating the macro definition). The only real question is which name to choose. Andres created a CommitFest entry targeting the PostgreSQL 20 development cycle, indicating intent to commit this early in the cycle to minimize merge conflicts with in-flight patches (like index prefetching) that use the macro heavily.

The thread shows no opposition whatsoever to renaming — only mild bikeshedding on the exact target name. Given Andres's committer status and ownership of the proposal, he will likely make the final call between pg_always_inline and pg_mustinline.