CI
Appliesapplies0d behind master
Buildsuccess2m 14s / 4m 55s
Tests1023 / 1023
GitHub runGitHub branchCI history
Participants
Erik Rijkers
Erik Rijkers
Alvaro Herrera
Alvaro Herrera
Daniel Gustafsson
Daniel Gustafsson
Attachments
Download Latest Patchset
+2-2
Show all attachments
Show all patchsets
Thread Outline
#1Erik RijkersErik Rijkers
Aug 16, 14:30
#2Alvaro Herrera↳Alvaro Herrerato Erik Rijkers (#1)
Aug 16, 16:21
#3Daniel Gustafsson↳Daniel Gustafssonto Alvaro Herrera (#2)
Aug 16, 20:16

pgcrypto.sgml: built in -> built-in

Started by Erik Rijkers7 days ago3 messageshackers
Beta feature

Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.

appliessuccessCI history

You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:

docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253432
psql -h localhost -U postgres

Built from patchset v1 (message #1), August 23, 2026 at 05:19 PM.

Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:

git clone --branch t253432_1 https://github.com/hackorum-dev/postgres.git

In a checkout you already have, add the fork once:

git remote add hackorum https://github.com/hackorum-dev/postgres.git

then, for this patchset and every later one:

git fetch hackorum t253432_1 && git checkout t253432_1

Patchset v1 (message #1) is on t253432_1

Jump to latest
#1Erik Rijkers
Erik Rijkers
er@xs4all.nl

Hi,

The documentation contains the word 'built-in' (with hyphen) more than
200 times so let's correct the 2x 'built in' in doc/src/sgml/pgcrypto.sgml

Thanks,

Erik

--- ./doc/src/sgml/pgcrypto.sgml.orig   2026-08-16 16:19:51.927578666 +0200
+++ ./doc/src/sgml/pgcrypto.sgml        2026-08-16 16:21:02.867577715 +0200
@@ -1268,7 +1268,7 @@
      <listitem>
       <para>
        <varname>pgcrypto.builtin_crypto_enabled</varname> determines if the
-      built in crypto functions <function>gen_salt()</function>, and
+      built-in crypto functions <function>gen_salt()</function>, and
        <function>crypt()</function> are available for use. Setting this to
        <literal>off</literal> disables these functions. 
<literal>on</literal>
        (the default) enables these functions to work normally.
@@ -1277,7 +1277,7 @@
       </para>
       <para>
        <function>pgp_sym_encrypt()</function> and
-      <function>pgp_pub_encrypt()</function> do not use built in crypto so
+      <function>pgp_pub_encrypt()</function> do not use built-in crypto so
        they are not affected.
       </para>
      </listitem>

Attachments:

t253432_1
pgcrypto.sgml.20260816.difftext/x-patch; charset=UTF-8; name=pgcrypto.sgml.20260816.diffDownload+2-2
#2Alvaro Herrera
Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Erik Rijkers (#1)
Re: pgcrypto.sgml: built in -> built-in

Hello,

On 2026-Aug-16, Erik Rijkers wrote:

The documentation contains the word 'built-in' (with hyphen) more than 200
times so let's correct the 2x 'built in' in doc/src/sgml/pgcrypto.sgml

Well observed. We do have "builtin" a number of times though. Do we
want to change those too? For example

contrib/pgcrypto/pgcrypto.c- DefineCustomEnumVariable("pgcrypto.builtin_crypto_enabled",
contrib/pgcrypto/pgcrypto.c: "Sets if builtin crypto functions are enabled.",
contrib/pgcrypto/pgcrypto.c: "\"on\" enables builtin crypto, \"off\" unconditionally disables and \"fips\" "
contrib/pgcrypto/pgcrypto.c: "will disable builtin crypto if OpenSSL is in FIPS mode",
contrib/pgcrypto/pgcrypto.c- &builtin_crypto_enabled,
--
contrib/postgres_fdw/deparse.c- * If the constant has nondefault collation, either it's of a
contrib/postgres_fdw/deparse.c: * non-builtin type, or it reflects folding of a CollateExpr.
contrib/postgres_fdw/deparse.c- * It's unsafe to send to the remote unless it's used in a
--
contrib/postgres_fdw/option.c- /*
contrib/postgres_fdw/option.c: * Disallow OAuth options for now, since the builtin flow communicates
contrib/postgres_fdw/option.c- * on stderr by default and can't cache tokens yet.
--
contrib/test_decoding/test_decoding.c- *
contrib/test_decoding/test_decoding.c: * Some builtin types aren't quoted, the rest is quoted. Escaping is done
contrib/test_decoding/test_decoding.c- * per standard SQL rules.

doc/src/sgml/jit.sgml- <para>
doc/src/sgml/jit.sgml: <productname>PostgreSQL</productname> has builtin support to perform
doc/src/sgml/jit.sgml- <acronym>JIT</acronym> compilation using <ulink
--
doc/src/sgml/libpq.sgml- installation documentation</link> for information on how to enable support
doc/src/sgml/libpq.sgml: for Device Authorization as a builtin flow.
doc/src/sgml/libpq.sgml- </para>

There's a bunch we should leave alone, but the ones I quote above and a
few more are less clear to me (and I suspect we should also change to
"built-in").

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

#3Daniel Gustafsson
Daniel Gustafsson
daniel@yesql.se
In reply to: Alvaro Herrera (#2)
Re: pgcrypto.sgml: built in -> built-in

On 16 Aug 2026, at 18:21, Álvaro Herrera <alvherre@kurilemu.de> wrote:
On 2026-Aug-16, Erik Rijkers wrote:

The documentation contains the word 'built-in' (with hyphen) more than 200
times so let's correct the 2x 'built in' in doc/src/sgml/pgcrypto.sgml

Well observed.

Ugh, that's my bad.

We do have "builtin" a number of times though. Do we
want to change those too? For example

contrib/pgcrypto/pgcrypto.c- DefineCustomEnumVariable("pgcrypto.builtin_crypto_enabled",
contrib/pgcrypto/pgcrypto.c: "Sets if builtin crypto functions are enabled.",
contrib/pgcrypto/pgcrypto.c: "\"on\" enables builtin crypto, \"off\" unconditionally disables and \"fips\" "
contrib/pgcrypto/pgcrypto.c: "will disable builtin crypto if OpenSSL is in FIPS mode",
contrib/pgcrypto/pgcrypto.c- &builtin_crypto_enabled,

Another one of mine =( This one should be the same as the in the docs IMHO.

--
contrib/postgres_fdw/deparse.c- * If the constant has nondefault collation, either it's of a
contrib/postgres_fdw/deparse.c: * non-builtin type, or it reflects folding of a CollateExpr.
contrib/postgres_fdw/deparse.c- * It's unsafe to send to the remote unless it's used in a
--
contrib/postgres_fdw/option.c- /*
contrib/postgres_fdw/option.c: * Disallow OAuth options for now, since the builtin flow communicates
contrib/postgres_fdw/option.c- * on stderr by default and can't cache tokens yet.
--
contrib/test_decoding/test_decoding.c- *
contrib/test_decoding/test_decoding.c: * Some builtin types aren't quoted, the rest is quoted. Escaping is done
contrib/test_decoding/test_decoding.c- * per standard SQL rules.

Personally I'm not to worried about spelling fixes at this level in comments,
but the risk of causing backpatching pain is low so if someone wants to do the
work then thats all good.

doc/src/sgml/jit.sgml- <para>
doc/src/sgml/jit.sgml: <productname>PostgreSQL</productname> has builtin support to perform
doc/src/sgml/jit.sgml- <acronym>JIT</acronym> compilation using <ulink
--
doc/src/sgml/libpq.sgml- installation documentation</link> for information on how to enable support
doc/src/sgml/libpq.sgml: for Device Authorization as a builtin flow.
doc/src/sgml/libpq.sgml- </para>

+1 on these.

--
Daniel Gustafsson

← Back to Topics