mirror of
https://github.com/hanzoai/postgres.git
synced 2026-10-30 18:33:07 +00:00
91530068f6
* ci: rebuild with arm64 (trigger)
* sql: our names on the outside, upstream's on the inside
The image is built FROM postgres, so the server and its own entrypoint read
POSTGRES_* and PGDATA. Those are the BINARY's interface — renaming them in a
chart produces a chart that does not boot, which is why the catalog entry still
carried POSTGRES_USER.
So the rename happens at the BOUNDARY, once: a Hanzo surface sets SQL_USER,
SQL_PASSWORD, SQL_DB, SQL_DATA, and entrypoint.sh maps each to what the server
reads before exec'ing upstream's entrypoint. Nothing downstream of a Hanzo
values file says postgres.
Same move the fleet already makes elsewhere — kv:// replacing redis://, the s3
binary replacing weed. The fork owns its identifiers; that is what makes it a
fork rather than a retag.
Upstream names still work when set, and SQL_* wins when both are present, so
this landing does not break the running deployment — which sets POSTGRES_USER
today and keeps working until its values file is updated.
The healthcheck follows the same order: SQL_USER, then POSTGRES_USER, then a
hanzo default rather than a postgres one.
* sql: SQL_ only — no POSTGRES_ fallback
Accepting both names means both keep being set, both get documented, and the
rename never finishes. A compatibility shim is how an old name outlives the
thing that replaced it.
SQL_USER and SQL_DB are now REQUIRED and the container refuses to start without
them, naming what to set. The healthcheck uses ${SQL_USER:?} — no postgres
default to fall back into.
The mapping to POSTGRES_* still happens, once, inside entrypoint.sh, because the
server underneath is built FROM postgres and that is the binary's interface. It
is not a Hanzo surface: a values file, a chart, a KMS path and an env in a
manifest all say SQL_.
---------
Co-authored-by: Hanzo Dev <[email protected]>
40 lines
1.3 KiB
Bash
Executable File
40 lines
1.3 KiB
Bash
Executable File
#!/usr/bin/env bash
|
|
# Hanzo SQL entrypoint — our names, and only ours.
|
|
#
|
|
# The server underneath reads POSTGRES_* and PGDATA because it is built FROM
|
|
# postgres. That is the BINARY's interface, and it is not a Hanzo surface: a
|
|
# values file, a chart, a KMS path and an env in a manifest all say SQL_.
|
|
#
|
|
# The mapping happens HERE, once, at the boundary — the same move as kv://
|
|
# replacing redis:// and the s3 binary replacing weed. The fork owns its
|
|
# identifiers; that is what makes it a fork rather than a retag.
|
|
#
|
|
# THERE IS NO POSTGRES_* FALLBACK, deliberately. Accepting both means both keep
|
|
# being set, both get documented, and the rename never finishes — a compatibility
|
|
# shim is how an old name outlives the thing that replaced it. One name, one way.
|
|
set -euo pipefail
|
|
|
|
require() {
|
|
local ours="$1" theirs="$2"
|
|
if [ -z "${!ours:-}" ]; then
|
|
echo "sql: ${ours} is required (Hanzo SQL reads ${ours}, never ${theirs})" >&2
|
|
exit 1
|
|
fi
|
|
export "$theirs=${!ours}"
|
|
}
|
|
|
|
optional() {
|
|
local ours="$1" theirs="$2"
|
|
[ -n "${!ours:-}" ] && export "$theirs=${!ours}"
|
|
return 0
|
|
}
|
|
|
|
require SQL_USER POSTGRES_USER
|
|
require SQL_DB POSTGRES_DB
|
|
optional SQL_PASSWORD POSTGRES_PASSWORD
|
|
optional SQL_DATA PGDATA
|
|
optional SQL_HOST_AUTH_METHOD POSTGRES_HOST_AUTH_METHOD
|
|
optional SQL_INITDB_ARGS POSTGRES_INITDB_ARGS
|
|
|
|
exec docker-entrypoint.sh "$@"
|