Technical Analysis: Replacing Obsolescent egrep with grep -E in PostgreSQL Build Tools

Core Problem

Modern GNU grep implementations have begun emitting warnings when the egrep command is invoked directly:

egrep: warning: egrep is obsolescent; using grep -E

This warning surfaces during routine development workflows — in this case, while running pgperltidy (PostgreSQL's Perl code tidying tool) on a recently-updated Linux workstation. While the warning is cosmetic and does not break functionality, it represents a standards compliance gap in PostgreSQL's build and development tooling.

Standards Background

The egrep command has never been part of POSIX. The POSIX-standardized equivalent, grep -E (extended regular expressions via a flag), has been specified since at least POSIX.1-2008 (IEEE Std 1003.1-2008). The fact that egrep has worked ubiquitously across Unix systems for decades is a historical artifact — it was a separate binary in traditional Unix implementations — but its absence from the standard means relying on it is technically non-portable, even if practically universal.

GNU grep has now made this deprecation visible to users, which means PostgreSQL developers on modern Linux distributions will see noisy warnings during routine operations. This is the kind of issue that, while minor, degrades developer experience and can mask more important warnings in build output.

Proposed Solution

Tom Lane's patch is a straightforward global substitution: s/egrep/grep -E/g across the PostgreSQL source tree, with two deliberate exceptions:

1. port/aix/mkldexport.sh: Left untouched because AIX's standards conformance situation is uncertain, and the platform is unlikely to emit this particular warning. This is a pragmatic decision — AIX has its own POSIX compliance quirks, and the risk of breaking a platform-specific script outweighs the benefit of cosmetic cleanup.

2. configure (generated by Autoconf): No change needed because Autoconf's AC_PROG_EGREP macro already probes for grep -E first and falls back to egrep only if needed. This was addressed in Autoconf "decades ago," as Peter Eisentraut noted.

Refinement: Dropping Extended Regex Entirely

Peter Eisentraut made an astute observation: the existing egrep invocations in the affected scripts don't actually use any extended regular expression features (such as +, ?, {n,m}, |, or ()). They are using basic regex patterns that plain grep handles identically. Therefore, the cleanest fix is to replace egrep with plain grep rather than grep -E, eliminating the unnecessary flag entirely.

This is a small but meaningful improvement in code clarity — using grep -E when no extended features are needed would leave future readers wondering what extended regex syntax they're missing. Tom Lane agreed and adopted this refinement.

Architectural Significance

While this is a trivial patch in terms of code change, it touches on an important principle in PostgreSQL's build system philosophy: minimize dependence on non-standard tools and behaviors. PostgreSQL is famously portable across a wide range of Unix-like systems, and this portability is maintained through careful attention to exactly these kinds of standards compliance details. The project's build tooling (configure, Makefiles, shell scripts) targets POSIX as its baseline, with platform-specific accommodations isolated in port/ directories.

The decision to leave AIX untouched while cleaning up general-purpose scripts exemplifies this layered portability strategy.

Risk Assessment

Essentially zero. grep -E and grep are universally available on all platforms PostgreSQL targets. The behavioral semantics are identical for the patterns in question. The only conceivable risk would be on an extremely old or non-conformant system that somehow has egrep but not grep -E, which is not a realistic scenario for any supported platform.