diff --git a/content/post/postgres/rfc-extension-packaging-lookup.md b/content/post/postgres/rfc-extension-packaging-lookup.md
index df9872bc..1e453df7 100644
--- a/content/post/postgres/rfc-extension-packaging-lookup.md
+++ b/content/post/postgres/rfc-extension-packaging-lookup.md
@@ -7,7 +7,7 @@ description: |
   A proposal to modify the PostgreSQL core so that all files required for an
   extension live in a directory named for the extension, along with a search
   path to find extension directories.
-tags: [Postgres, Extensions, RFC, Packaging, Kubernetes, Docker, Packaging, Postgres.app]
+tags: [Postgres, Extensions, RFC, Packaging, Kubernetes, OCI, Packaging, Postgres.app]
 type: post
 draft: true
 ---
@@ -44,15 +44,16 @@ the patch will search in `/tmp/build/myext/opt/share`. This approach works for
 the packaging use case, which explicitly uses full paths with a prefix, but
 would be weird for other use cases.
 
-### Docker Immutability
+### OCI Immutability
 
-Docker images are immutable. To install persistent extensions in a running
-Docker container, one must create a persistent volume, map it to
-`SHAREDIR/extensions`, and copy over all the core extensions (or muck with
-[symlink magic]). Then do it again for shared object libraries (`PKGLIBDIR`),
-and perhaps also for other `pg_config` directories, like `--bindir`. Once it's
-all set up, one can install a new extension and its files will be distributed
-to the relevant persistent volumes.
+[OCI] (née Docker) images are immutable, while a container running an image
+contains a writeable but non-persistent file system. To install persistent
+extensions in a running container, one must create a persistent volume, map it
+to `SHAREDIR/extensions`, and copy over all the extensions it needs (or muck
+with [symlink magic]). Then do it again for shared object libraries
+(`PKGLIBDIR`), and perhaps also for other `pg_config` directories, like
+`--bindir`. Once it's all set up, one can install a new extension and its
+files will be distributed to the relevant persistent volumes.
 
 This pattern makes upgrades tricky, because the core extensions are mixed in
 with third-party extensions. Worse, the number of directories that must be
@@ -228,10 +229,10 @@ This will allow PostgreSQL to find and load the extension during the tests.
 The Postgres installation will not have been modified; only the
 `extension_path` will have changed.
 
-### Docker/Kubernetes
+### OCI/Kubernetes
 
-To allow extensions to be added to a Docker container and to persist beyond
-its lifetime, one or more [volumes] could be used. A couple of options:
+To allow extensions to be added to a OCI container and to persist beyond its
+lifetime, one or more [volumes] could be used. A couple of options:
 
 *   Mount the `--extdir-site` and/or `--extdir-vendor` directories as
     persistent volumes (or one volume and a subdirectory for each). Then any
@@ -240,11 +241,11 @@ its lifetime, one or more [volumes] could be used. A couple of options:
     uses the same persistent volume(s), can access the same extensions.
 
 *   Create separate images for each extension, and then "install" them by
-    using the [Kubernetes image volume feature] to mount them as read-only
-    volumes in the appropriate subdirectory of `--extdir-site` or
-    `--extdir-vendor`. Thereafter, any new containers would simply have to
-    mount all the same extension image volumes persistently provide the same
-    extensions to all containers.
+    using the [Kubernetes image volume feature] (currently in alpha) to mount
+    them as read-only volumes in the appropriate subdirectory of
+    `--extdir-site` or `--extdir-vendor`. Thereafter, any new containers would
+    simply have to mount all the same extension image volumes persistently
+    provide the same extensions to all containers.
 
 ### Postgres.app
 
@@ -397,11 +398,11 @@ shared_preload_extensions = 'pg_partman'
 ```
 
 To load a single shared module from an extension, give its name after the
-extension name and a slash. This example will load only the `pg_partman_bgw`
-shared module from the `pg_partman` extension:
+extension name and two colons. This example will load only the
+`pg_partman_bgw` shared module from the `pg_partman` extension:
 
 ```ini
-shared_preload_extensions = 'pg_partman/pg_partman_bgw'
+shared_preload_extensions = 'pg_partman::pg_partman_bgw'
 ```
 
 This change requires a one-time change to existing preload configurations on
@@ -459,7 +460,7 @@ the `*_preload_libraries` GUCs along with it.
 This RFC does not include or attempt to address the following issues:
 
 *   How to manage third-party shared libraries. Making system dependencies
-    consistent in a Docker/Kubernetes environment or for non-system binary
+    consistent in a OCI/Kubernetes environment or for non-system binary
     packaging patterns presents its own challenges, though they're not
     specific to PostgreSQL or the patterns described here. Research is ongoing
     into potential solutions, and will be addressed elsewhere.
@@ -469,6 +470,7 @@ This RFC does not include or attempt to address the following issues:
   [discussion]: https://postgr.es/m/E7C7BFFB-8857-48D4-A71F-88B359FADCFD@justatheory.com
   [Christoph Berg]: https://www.df7cb.de
   [destdir]: https://commitfest.postgresql.org/50/4913/
+  [OCI]: https://opencontainers.org "Open Container Initiative"
   [symlink magic]: https://speakerdeck.com/ongres/postgres-extensions-in-kubernetes?slide=14
     "Postgres Extensions in Kubernetes: StackGres"
   [Kubernetes image volume feature]: https://kubernetes.io/docs/tasks/configure-pod-container/image-volumes/