Why does the code location inherit the rds connection info from daemon when a schedule is triggered? Can the postgres host be set separately in the code location?

When a schedule is triggered in Dagster, the code location may attempt to connect to the database using the PostgreSQL connection parameters configured in the Dagster instance. This behavior is due to the fact that certain Dagster system processes, such as the daemon, may directly read from or write to the instance database. For example, if a sensor is running inside the code location and queries the instance, it would need access to the database. The documentation does not explicitly state whether the PostgreSQL host can be set separately in the code location. However, it does mention that code locations are loaded in a different process and communicate with Dagster system processes over an RPC mechanism. This architecture allows for updates to user code to be picked up by the Dagster webserver/UI without a restart and supports multiple code locations with a single instance of the webserver/UI. Each code location can be sourced from a separate Python environment, allowing teams to manage their dependencies separately. If you need to have different PostgreSQL connection settings for your code location, you might consider setting environment variables that override the default connection parameters when the code location is launched. This approach is commonly used in containerized environments, such as Kubernetes or Docker, where environment variables can be set per container. However, since the documentation does not provide a clear answer on setting the PostgreSQL host separately within a code location, it would be best to refer to the specific configuration options available for your deployment scenario or consult with the Dagster community or support channels for further guidance.