What happens?
Problem
In the pgduckdb/pgduckdb Docker image, setting MOTHERDUCK_TOKEN (or motherduck_token) implicitly enables MotherDuck during initialization.
This happens because the image init script unconditionally runs CALL duckdb.enable_motherduck(<token>) when it detects the token env var:
docker/init.d/0002-enable-md-pg_duckdb.sql:
- reads
MOTHERDUCK_TOKEN / motherduck_token
- calls
duckdb.enable_motherduck(:token) if present
Why this is an issue
duckdb.enable_motherduck(token, default_database) only applies default_database when the motherduck foreign server is created. If the Docker init script has already created the server (without default_database), users cannot set the default database at startup.
This effectively forces users into the “drop/recreate server” workflow to change the default database, as documented here:
https://github.com/duckdb/pg_duckdb/blob/main/docs/motherduck.md#changing-the-default-database
In practice this makes the container’s “just set MOTHERDUCK_TOKEN” path hard to use for real deployments where the default DB needs to be controlled declaratively at boot time.
Requested change
Please consider one of the following:
- Add an env var for the default database (e.g.
MOTHERDUCK_DEFAULT_DATABASE) and update the init script to call:
CALL duckdb.enable_motherduck(:token, :'default_db'); when provided, otherwise keep current behavior.
or
- Disable automatic enabling by default, and require an explicit opt-in env var (e.g.
PGDUCKDB_ENABLE_MOTHERDUCK=1) before the init script runs duckdb.enable_motherduck(...).
Either option would preserve a good “it just works” experience while making it possible to configure default_database cleanly at container start.
Expected outcome
- Users can set both
MOTHERDUCK_TOKEN and the default MotherDuck database non-interactively at init time, without needing to drop/recreate the server afterward.
To Reproduce
docker run -d -e POSTGRES_PASSWORD=duckdb -e MOTHERDUCK_TOKEN pgduckdb/pgduckdb:18-v1.1.1
OS:
Linux
pg_duckdb Version (if built from source use commit hash):
1.1.1
Postgres Version (if built from source use commit hash):
18
Hardware:
No response
Full Name:
Muhammad Jarir Kanji
Affiliation:
Indus Data
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a stable release
Did you include all relevant data sets for reproducing the issue?
No - Other reason (please specify in the issue body)
Did you include all code required to reproduce the issue?
Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?
What happens?
Problem
In the
pgduckdb/pgduckdbDocker image, settingMOTHERDUCK_TOKEN(ormotherduck_token) implicitly enables MotherDuck during initialization.This happens because the image init script unconditionally runs
CALL duckdb.enable_motherduck(<token>)when it detects the token env var:docker/init.d/0002-enable-md-pg_duckdb.sql:MOTHERDUCK_TOKEN/motherduck_tokenduckdb.enable_motherduck(:token)if presentWhy this is an issue
duckdb.enable_motherduck(token, default_database)only appliesdefault_databasewhen themotherduckforeign server is created. If the Docker init script has already created the server (withoutdefault_database), users cannot set the default database at startup.This effectively forces users into the “drop/recreate server” workflow to change the default database, as documented here:
https://github.com/duckdb/pg_duckdb/blob/main/docs/motherduck.md#changing-the-default-database
In practice this makes the container’s “just set
MOTHERDUCK_TOKEN” path hard to use for real deployments where the default DB needs to be controlled declaratively at boot time.Requested change
Please consider one of the following:
MOTHERDUCK_DEFAULT_DATABASE) and update the init script to call:CALL duckdb.enable_motherduck(:token, :'default_db');when provided, otherwise keep current behavior.or
PGDUCKDB_ENABLE_MOTHERDUCK=1) before the init script runsduckdb.enable_motherduck(...).Either option would preserve a good “it just works” experience while making it possible to configure
default_databasecleanly at container start.Expected outcome
MOTHERDUCK_TOKENand the default MotherDuck database non-interactively at init time, without needing to drop/recreate the server afterward.To Reproduce
OS:
Linux
pg_duckdb Version (if built from source use commit hash):
1.1.1
Postgres Version (if built from source use commit hash):
18
Hardware:
No response
Full Name:
Muhammad Jarir Kanji
Affiliation:
Indus Data
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a stable release
Did you include all relevant data sets for reproducing the issue?
No - Other reason (please specify in the issue body)
Did you include all code required to reproduce the issue?
Did you include all relevant configuration (e.g., CPU architecture, Linux distribution) to reproduce the issue?