Order views by Postgres oid #117
Conversation
| "parents", | ||
| "children", | ||
| "people", | ||
| "people_with_names" |
There was a problem hiding this comment.
Put a comma after the last item of a multiline array.
Our previous strategy of: 1. Relying on postgres to give us the views from `pg_views` and `pg_matviews` in the correct order 2. Always dumping materialized views last was incorrect on both counts. Those tables have no specific ordering so the results can come back in any order. Also, we can have views that depend on materialized views. We need to get all of the views - materialized and otherwise - from a single query and we need them to be ordered in the same order they were created. I inspected the definitions of `pg_views` and `pg_matviews` and noticed they are both built from pg_class. Querying on that table gives us a way to get both the views and materialized views in a single query. Ordering by 'oid' is the simplest way to order them by insertion order. Dropping a view that depends on a child view also requires dropping that child view, so ordering in this manner should be sufficient. This technically means we don't need the connection decorator I introduced in the previous change, but we know we will be using that functionality very soon in another change, so I'm leaving it be for now. I ran the improved test of `#views` in the `postgres_spec` hundreds of times and got a consistent, valid order every time.
derekprior
force-pushed
the
dp-view-ordering
branch
from
e724658
to
fa81d50
Compare
|
Looks great. Good find Derek. Thanks for looking into it.
|
Our previous strategy of:
pg_viewsandpg_matviewsin the correct orderwas incorrect on both counts. Those tables have no specific ordering so
the results can come back in any order. Also, we can have views that
depend on materialized views.
We need to get all of the views - materialized and otherwise - from a
single query and we need them to be ordered in the same order they were
created.
I inspected the definitions of
pg_viewsandpg_matviewsand noticedthey are both built from pg_class. Querying on that table gives us a way
to get both the views and materialized views in a single query. Ordering
by 'oid' is the simplest way to order them by insertion order. Dropping
a view that depends on a child view also requires dropping that child
view, so ordering in this manner should be sufficient.
This technically means we don't need the connection decorator I
introduced in the previous change, but we know we will be using that
functionality very soon in another change, so I'm leaving it be for now.
I ran the improved test of
#viewsin thepostgres_spechundreds oftimes and got a consistent, valid order every time.