You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CODD_EXTRA_ROLES currently is the roles to verify other than the one in the connection string. This is not bad but can be improved substantially. Ideally codd would:
Infer which roles to verify by extracting all roles that are involved with db objects somehow. For example, namespace/table/view/function owners but also roles with explicit permissions granted to any db object.
The role in the connection string would still automatically be included, as migrations run with it by default.
How about roles used in custom connection strings in some migration? Despite the argument that some migration ran/will run with that user (thus it makes sense for it to be included) this might actually be a little unexpected, and can change what roles to consider once migrations are deleted from disk, which can be problematic if someone decides to ship a subset of pending migrations when deploying or other things. So we ignore those. Users can still add them to CODD_EXTRA_ROLES if need be (and if they aren't already related to db objects, of course).
What about roles that roles belong to? For example an admin role being part of the writer role, with writer not explicitly related to any db objects but admin being so. Do we verify writer? Read the docs to learn how things work here.
After implementing this, CODD_EXTRA_ROLES will make a perfectly optional variable and give users liberty to create/manage roles without being worried about changing the env var accordingly.
The text was updated successfully, but these errors were encountered:
CODD_EXTRA_ROLES
currently is the roles to verify other than the one in the connection string. This is not bad but can be improved substantially. Ideally codd would:CODD_EXTRA_ROLES
if need be (and if they aren't already related to db objects, of course).admin
role being part of thewriter
role, withwriter
not explicitly related to any db objects butadmin
being so. Do we verifywriter
? Read the docs to learn how things work here.After implementing this,
CODD_EXTRA_ROLES
will make a perfectly optional variable and give users liberty to create/manage roles without being worried about changing the env var accordingly.The text was updated successfully, but these errors were encountered: