···260260261261This leaves a small gap of a couple of weeks after the latest minor release and the end of our support window for the .05 release, in which there could be an emergency release to other major versions of PostgreSQL - but not the oldest major we have in that branch. In that case: If we can't trivially patch the issue, we will mark the package/version as insecure **immediately**.
262262263263+## `pg_config` {#module-services-postgres-pg_config}
264264+265265+`pg_config` is not part of the `postgresql`-package itself.
266266+It is available under `postgresql_<major>.pg_config` and `libpq.pg_config`.
267267+Use the `pg_config` from the postgresql package you're using in your build.
268268+269269+Also, `pg_config` is a shell-script that replicates the behavior of the upstream `pg_config` and ensures at build-time that the output doesn't change.
270270+271271+This approach is done for the following reasons:
272272+273273+* By using a shell script, cross compilation of extensions is made easier.
274274+275275+* The separation allowed a massive reduction of the runtime closure's size.
276276+ Any attempts to move `pg_config` into `$dev` resulted in brittle and more complex solutions
277277+ (see commits [`0c47767`](https://github.com/NixOS/nixpkgs/commit/0c477676412564bd2d5dadc37cf245fe4259f4d9), [`435f51c`](https://github.com/NixOS/nixpkgs/commit/435f51c37faf74375134dfbd7c5a4560da2a9ea7)).
278278+279279+* `pg_config` is only needed to build extensions or in some exceptions for building client libraries linking to `libpq.so`.
280280+ If such a build works without `pg_config`, this is strictly preferable over adding `pg_config` to the build environment.
281281+282282+ With the current approach it's now explicit that this is needed.
283283+284284+263285## Options {#module-services-postgres-options}
264286265287A complete list of options for the PostgreSQL module may be found [here](#opt-services.postgresql.enable).