Skip to content

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

Merged
merged 14 commits into from
Mar 28, 2024
Merged

Support introspecting composite types #391

merged 14 commits into from
Mar 28, 2024

Conversation

plcplc
Copy link
Contributor

@plcplc plcplc commented Mar 27, 2024

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.

composite_types
.0
.retain(|t, _| occurring_type_names.contains(t));
(occurring_scalar_types, composite_types)
Copy link
Contributor

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) {
Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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!

Copy link
Contributor

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.

Copy link
Contributor Author

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

@plcplc plcplc enabled auto-merge March 28, 2024 08:53
@plcplc plcplc added this pull request to the merge queue Mar 28, 2024
Merged via the queue into main with commit cfd0d29 Mar 28, 2024
35 checks passed
@plcplc plcplc deleted the plc/issues/PG-62 branch March 28, 2024 13:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants