-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for fetching non-public schemas. #96
Conversation
|
||
return concurrent.GetAll(ctx, tableFutures...) | ||
} | ||
tables = filterSliceByName( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is way more flexible to do this filtering in-memory rather than in the query. We can easily support things like regex and complex nested operations in the future (unions of intersections, etc).
@@ -25,8 +29,8 @@ LEFT JOIN | |||
pg_catalog.pg_namespace AS parent_namespace | |||
ON parent_c.relnamespace = parent_namespace.oid | |||
WHERE | |||
c.relnamespace | |||
= (SELECT oid FROM pg_catalog.pg_namespace WHERE nspname = 'public') | |||
table_namespace.nspname NOT IN ('pg_catalog', 'information_schema') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the same filter Postgres uses in its pg_stat_user_tables view to filter down from pg_stat_all_tables.
970ecbc
to
9863ee2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Description
This only adds support for fetching non-public schemas. This does actually allow generating migration plans for non-public schemas because we will need plumb several into the sql generation code to account for schemas.
I opted to do the filtering in-memory because it is way more flexible to do the filtering in-memory rather than in the queries. We can easily support things like regex and complex nested operations in the future (unions of intersections, etc). I don't expect the filters to significantly reduce the number of schema objects being fetched, so the performance impact of doing it in-memory is minimal.
Motivation
#94
Testing
Tested via unit tests