This message was deleted.

If you want to chain correctly, then create a

postgresql.Provider

after the CloudSQL instance creation and create the roles passing the provider to it. Because of this chaining, it will wait correctly:

const dbServerResource = new ... // CloudSQL creation here

const databaseProvider = new postgresql.Provider("adminconnection", {
    username: dbAdminUser,
    password: dbAdminPassword,
    superuser: false,
    host: dbServerResource.fqdn,
    port: 5432
})

const databaseRole = new postgresql.Role("your_role", {
    connectionLimit: 4,
    login: true,
    name: "your_role_name",
    password: dbRolePassword
},
{
    provider: databaseProvider
})

@limited-rainbow-51650, thanks a lot! I will try that. I do see a

pulumi_postgresql.Provider

class in the postgresq l module.

@better-actor-92669 the PostgreSQL provider uses the psql go client library. It connects directly to the Postgres port (default: 5432). It supports SSL protected connections by default. I didn’t have to do anything special to connect e.g. to an Azure PostgreSQL server.

@limited-rainbow-51650, to be specific, it uses libpq library. Do you specify client cert, client key and ca cert via runtime?

I didn’t. To be honest, I’m actually assuming I’m on an SSL protected connection. Good that you trigger me on that. I should verify this explicitly.

Predefined config file for libpq works, but if you create Pulumi Objects via runtime, it is not possible (at least for python sdk and pulumi_postgresql) module to access its properties, that is why I wandered how you do that

Strange. I would file an issue in the

pulumi-postgresql

provider Github repo for further investigation. At runtime, you should be able to set all properties on a newly created Provider object. If that is not available, an issue is your means to communicate your desire. 😉

Yeah, I tried to set up some ENVIRONMENTAL variables as a workaround, but @many-garden-84306 advocates against it in asynchronous operation 🙂