-
Notifications
You must be signed in to change notification settings - Fork 5
Support introspecting composite types #391
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
Conversation
composite_types | ||
.0 | ||
.retain(|t, _| occurring_type_names.contains(t)); | ||
(occurring_scalar_types, composite_types) |
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.
Why do we both mutate composite_types
and return it?
mut occurring_scalar_types: BTreeSet<metadata::ScalarType>, | ||
occurring_type_names: BTreeSet<String>, | ||
mut composite_types: metadata::CompositeTypes, | ||
) -> (BTreeSet<metadata::ScalarType>, metadata::CompositeTypes) { |
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.
The mix of mutated "in/out" parameters and return values is confusing me. I'd rather pick one or the other.
Can we just mutate occurring_type_names
?
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.
I'm not quite sure I get this.
AFAIK a an 'out parameter' would be a &mut
, right?
All parameters to this function are owned, which is also why some of them get returned afterwards.
I'm totally open to suggestions. It wasn't obvious what would be the best way to code this function TBH.
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.
Ah, that makes sense now. Thanks!
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.
I cannot promise I completely understand this SQL, but I understand it about as well as I'm ever going to.
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.
That's understandable. It's mostly made up of semi-internal postgres details :p
What
This PR adds the ability of the introspection query to detect composite types, meaning user-defined record types that do not arise from a table but exist as standalone definitions.
This even discovered a typo in the previous, manually crafted composite type metadata.
Support for cockroachdb is limited here until cockroachdb/cockroach#109675 is released.
How
Introspection Query now captures composite types, filtering out the tables. Making metadata json out of these is quite similar to how we already did tables, so no huge surprises here.
Occurring types logic now becomes somewhat more complex because we can no longer simply look at which type names are used in the collections we track. A composite type occurring in say, a table column, may refer to scalar types that don't occur anywhere else, and even other composite types. Occurring type discovery thus becomes an iterative procedure rather than a single pass.