ECPG(1)

💅 ECPG(1) — the embedded SQL C preprocessor, but make it make sense

okay so first things first, the page header says ECPG(1) and this lives in the PostgreSQL 17.11 Documentation manual, bestie. Now let's get into it 🫶

✨ NAME ✨

ecpg — the embedded SQL C preprocessor. that's it, that's the vibe.

✨ SYNOPSIS ✨

ecpg [option...] file...

🦋 DESCRIPTION 🦋

so ecpg is the embedded SQL preprocessor for C programs, no cap. what it does is iconic: it takes C programs that have SQL statements embedded in them and converts them into normal C code by swapping out the SQL invocations for special function calls. then you just run the output files through any C compiler tool chain and you're good 💖

ecpg will convert each input file you give it on the command line into the corresponding C output file. if an input file name has no extension at all, .pgc is assumed (default behavior, love that for us). the file's extension gets replaced by .c to build the output file name. but — and this is the fun part — you can override the output file name with the -o option 😌

and if an input file name is literally just -, then ecpg reads the program from standard input (and writes to standard output, unless you override that with -o). stream it, slay.

heads up bestie: this reference page does not describe the embedded SQL language itself. see Chapter 34 for more on that topic ✨

---

🎀 OPTIONS 🎀

ecpg accepts the following command-line arguments:

• -c — automatically generate certain C code from SQL code. currently this works for EXEC SQL TYPE. it's giving auto-pilot 💅
• -C mode — set a compatibility mode. mode can be INFORMIX, INFORMIX_SE, or ORACLE.
• -D symbol[=value] — define a preprocessor symbol, equivalently to the EXEC SQL DEFINE directive. if no value is specified, the symbol is defined with the value 1.
• -h — process header files. when this option is specified, the output file extension becomes .h not .c, and the default input file extension is .pgh not .pgc. also, the -c option is forced on. it's the whole package, periodt.
• -i — parse system include files as well. go deeper 🔥
• -I directory — specify an additional include path, used to find files included via EXEC SQL INCLUDE. the defaults are . (current directory), /usr/local/include, the PostgreSQL include directory which is defined at compile time (default: /usr/local/pgsql/include), and /usr/include, in that order. order matters, iykyk 👑
• -o filename — specifies that ecpg should write all its output to the given filename. write -o - to send all output to standard output.
• -r option — selects run-time behavior. option can be one of the following:
  • no_indicator — do not use indicators but instead use special values to represent null values. historically there have been databases using this approach. retro, honestly.
  • prepare — prepare all statements before using them. libecpg will keep a cache of prepared statements and reuse a statement if it gets executed again. if the cache runs full, libecpg will free the least used statement. it's giving smart-cache main character energy ✨
  • questionmarks — allow question mark as placeholder for compatibility reasons. this used to be the default long ago. throwback 🕰️
• -t — turn on autocommit of transactions. in this mode, each SQL command is automatically committed unless it is inside an explicit transaction block. in the default mode, commands are committed only when EXEC SQL COMMIT is issued. pick your fighter 💀
• -v — print additional information including the version and the "include" path.
• --version — print the ecpg version and exit.
• -?, --help — show help about ecpg command line arguments, and exit. when in doubt, --help it out 🫶

---

⭐ NOTES ⭐

okay so this part is important, don't skip it 🙈

when compiling the preprocessed C code files, the compiler needs to be able to find the ECPG header files in the PostgreSQL include directory. therefore, you might have to use the -I option when invoking the compiler (e.g., -I/usr/local/pgsql/include). don't forget it, bestie, or you'll be sad 😭

programs using C code with embedded SQL have to be linked against the libecpg library, for example using the linker options:

-L/usr/local/pgsql/lib -lecpg

the value of either of these directories that is appropriate for the installation can be found out using pg_config(1). bless pg_config, honestly 🧚

---

🌈 EXAMPLES 🌈

if you have an embedded SQL C source file named prog1.pgc, you can create an executable program using the following sequence of commands:

ecpg prog1.pgc
cc -I/usr/local/pgsql/include -c prog1.c
cc -o prog1 prog1.o -L/usr/local/pgsql/lib -lecpg

that's preprocess, compile, link. three steps, zero stress, we love a pipeline 💖

---

and that's the whole page, bestie 💅 shipped straight from PostgreSQL 17.11, dated 2026, in the ECPG(1) manual — go forth and embed your SQL, you absolute icon 🎀✨