Skip to content
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

use pgx::prelude::*; #699

Merged
merged 21 commits into from
Sep 22, 2022

Conversation

workingjubilee
Copy link
Member

As an alternative to exporting all identifiers from PGX, this PR introduces a module for importing all commonly-used, distinctive identifiers from PGX. It also makes it much less likely that a random name introduced by a user will shadow any of PGX's own names by fully qualifying the names used in various macro expansions.

Previously, PGX has relied on `use pgx::*;` in order to make the framework happen.
However, this severely pollutes the namespaces of our users. We're hogging idents.
Worse, a user collision with our identifiers may result in displacing our logic,
resulting in undesirable and unexpected side effects.

PGX depends on the macros being at least mostly correct in order to be sound,
so this is not at all acceptable.
This macro is also fairly critical to PGX's functioning,
being integral to any and all "table"-like returns.
`use pgx::prelude::*;` is already sufficient for some test files now,
@workingjubilee
Copy link
Member Author

Assuming PL/Rust works with use pgx::prelude::*;, is this more like what you had in mind? @JohnHVancouver

Copy link
Contributor

@Hoverbear Hoverbear left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means we can clean up a lot of the pgx::* stuff ya? Love it.

@JohnHVancouver
Copy link
Contributor

@workingjubilee does that mean the user-code can no longer access all of pgx? Or just makes it easier/cleaner to detect

@workingjubilee
Copy link
Member Author

Currently the latter, but it makes the former humanly possible without completely breaking... uh, everything.

@workingjubilee workingjubilee added the refactor Changes would be considered a refactor of existing functionality. label Sep 21, 2022
@workingjubilee
Copy link
Member Author

I mentioned that a lot of PGX's logic is deeply entangled, and this PR involves sorting... most of that out. Before this PR, PGX has what amounts to an existential dependency on the glob-export that you do not enjoy. #615 made the situation significantly better, but it still remains a problem, even after this amount of refactoring.

@workingjubilee
Copy link
Member Author

This now makes all of pgx-tests work without the use pgx::*; glob. I am going to address pgx-examples in a later PR. Though it removes heap_tuple and iter from the public exports, these were added during the current 0.4.5 ~ 0.5.0 interstitial period, so hopefully no one is already depending on them.

@workingjubilee workingjubilee merged commit b48c8db into pgcentralfoundation:develop Sep 22, 2022
@workingjubilee
Copy link
Member Author

Well... except PL/Rust.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactor Changes would be considered a refactor of existing functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants