Home Explore Blog CI



postgresql

12th chunk of `doc/src/sgml/sources.sgml`
0c6f5ca6d68a32c4c082826907a10f857984b82e0b57b8870000000100000a01
 linkend="nls-guidelines"/>
    to avoid making life difficult for translators.
   </para>
  </simplesect>

  </sect1>

  <sect1 id="source-conventions">
   <title>Miscellaneous Coding Conventions</title>

   <simplesect id="source-conventions-c-standard">
    <title>C Standard</title>
    <para>
     Code in <productname>PostgreSQL</productname> should only rely on language
     features available in the C99 standard. That means a conforming
     C99 compiler has to be able to compile postgres, at least aside
     from a few platform dependent pieces.
    </para>
    <para>
     A few features included in the C99 standard are, at this time, not
     permitted to be used in core <productname>PostgreSQL</productname>
     code. This currently includes variable length arrays, intermingled
     declarations and code, <literal>//</literal> comments, universal
     character names. Reasons for that include portability and historical
     practices.
    </para>
    <para>
     Features from later revisions of the C standard or compiler specific
     features can be used, if a fallback is provided.
    </para>
    <para>
     For example <literal>_Static_assert()</literal> and
     <literal>__builtin_constant_p</literal> are currently used, even though
     they are from newer revisions of the C standard and a
     <productname>GCC</productname> extension respectively. If not available
     we respectively fall back to using a C99 compatible replacement that
     performs the same checks, but emits rather cryptic messages and do not
     use <literal>__builtin_constant_p</literal>.
    </para>
   </simplesect>

   <simplesect id="source-conventions-macros-inline">
    <title>Function-Like Macros and Inline Functions</title>
    <para>
     Both macros with arguments and <literal>static inline</literal>
     functions may be used. The latter are preferable if there are
     multiple-evaluation hazards when written as a macro, as e.g., the
     case with
<programlisting>
#define Max(x, y)       ((x) > (y) ? (x) : (y))
</programlisting>
     or when the macro would be very long. In other cases it's only
     possible to use macros, or at least easier.  For example because
     expressions of various types need to be passed to the macro.
    </para>
    <para>
     When the definition of an inline function references symbols
     (i.e., variables, functions) that are only available as part of the
     backend, the function may not be visible when included from frontend
     code.
<programlisting>
#ifndef FRONTEND
static inline

Title: Coding Conventions for PostgreSQL
Summary
The text outlines coding conventions for PostgreSQL, including the use of the C99 standard, avoidance of certain features, and guidelines for using function-like macros and inline functions. It emphasizes the importance of providing fallbacks for features from later revisions of the C standard and compiler-specific features. The text also discusses the use of macros with arguments and static inline functions, and provides examples of when to use each, considering factors such as multiple-evaluation hazards and code visibility.