3 posts tagged with "dev-url"

Why does Atlas not detect PostgreSQL event_trigger objects when using --dev-url with search_path=public?

Question​

An AWS RDS MySQL schema creates IAM-authenticated users, for example:

CREATE USER 'app_iam' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';

Running atlas migrate diff (or any command that uses the dev-database) against a standard mysql Docker image fails, because that plugin exists only on RDS:

Error: failed to run `atlas migrate diff`: Error: sql/migrate: read migration directory state:
sql/migrate: executing statement "CREATE USER 'app_iam' IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS';"
from version "20260602081826": Error 1524 (HY000): Plugin 'AWSAuthenticationPlugin' is not loaded

Must the dev-url point at a real RDS instance, or can the dev-database run locally in Docker?

Question​

Schemas that use postgres_fdw reference an upstream PostgreSQL server (SERVER, USER MAPPING, FOREIGN TABLE). That upstream server is often reachable only from inside the VPC of environments such as staging or production: local workstations and CI runners have no network path to it.

Working with such schemas in Atlas, whether for schema planning, schema testing, or simulating the real setup locally, triggers an FDW connection attempt on the dev-database that fails with errors such as:

08001 could not connect to server "upstream_db"

A common case is a materialized view that selects from a foreign table, which opens the FDW connection at CREATE time. What is the recommended pattern for stubbing the foreign server so that schema design, plan, lint, and diff run hermetically against the dev-database?