Bobbie Soedirgo

Hmm, the `postgres` role used for deploying isn't a superuser, so it can't create/manage extensions. One (ugly) workaround is to remove all extension-related stuff from the migration, deploy, then add...

Sorry about that. The known major constraints should be in the issue tracker already (`auth.users` triggers, storage policies, extensions). We won't be allowing any superuser access in the future, so...

This is now supported.

Side note: have you looked into [Zapatos](https://jawj.github.io/zapatos/index.html)? Feels like it's exactly what we want, but I don't know how good the generated types are.

Yeah, I think it's best if different languages are handled separately. All type systems have their own idiosyncrasies, so it's best to avoid adding abstractions esp. if it might end...

Hey @wasabigeek, sorry for the late response here, got sidetracked... I've given this some thought, and I think it's better to hold off the PR for now and wait for...

cc @phamhieu

How about adding a new optional env var `PG_META_DB_SSL_ROOT_CERT`? Similar with `PG_META_DB_SSL_MODE`, if specified we can append that to the connection string. Happy to accept a PR for it.

I don't think there's an OID for "grants", but looking at [this](https://stackoverflow.com/questions/22315030/retrieving-all-object-privileges-for-specific-role), it's possible to get OIDs for a grantee-grantor-privileges relation. [`pg_class` docs](https://www.postgresql.org/docs/current/catalog-pg-class.html) [Another related SO thread](https://stackoverflow.com/questions/39811058/how-can-i-review-all-database-and-object-grants-for-a-role)

UI stuff aside: yes, we can make constraints be defined on tables the same way e.g. policies and primary keys are. The idea for this feature is for it to...