-
-
Notifications
You must be signed in to change notification settings - Fork 249
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
remove dlopen hack #1468
remove dlopen hack #1468
Conversation
This is... this is exciting! |
216303e
to
9c2b706
Compare
Curious, why do we want to support non-accessible items? |
Using linker sections again would be annoying, but could be plausible. However:
This sounds like it will eventually prove to be an unreasonable expectation, if it is not one already? |
Does this support cross-compilation? |
To be clearer: when pgrx performs code expansion, even if the programmer doesn't put |
I suppose schema gen has to happen on the build host anyways, so we're hoping programmers don't do anything silly like combining |
They can take advantages of qemu. We had the idea in #981 (comment) |
We can use |
Yes, I think that sounds acceptable. My main concern was that anything based on linker sections is historically prone to dying when it slams into the rocks of platform-specific nonsense. So we simply don't have sufficient contributors to reasonably work through that and fix while also maintaining the other parts of pgrx, and they always cause issues in ways that are hard to even identify as a problem with the platform-specific thing. I understand the concern about breakage. 0.12 is likely to have quite enough to fix to update to as-is, because it will land fixes for lifetime issues, so I agree we don't want to have even more breakage in this cycle. |
11255f3
to
f214499
Compare
CI passed and I will continue to finish unfinished work. |
This looks very interesting! I discussed this briefly with the other maintainers. Another note against the ctor crate: @thomcc mentions that rustc has problems with... accidentally discarding ctors. Only A concern of build performance regression was brought up, but at the same time, we don't really feel a regression that isn't "literally doubling build time" is worth blocking this over: pgrx has a bunch of low-hanging fruit on build time, and having a much less cursed build setup is worth sacrificing at least some performance. |
|
Hmm. That currently requires a |
ff58e46
to
cb893fc
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.
This unfortunately seems to make using the command line tools to interact with things in this repo a bit... confusing:
$ cargo run --bin strings/pgrx_embed
error: no bin target named `strings/pgrx_embed`.
Available bin targets:
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
cargo-pgrx
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx-version-updater
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
pgrx_embed
This would be understandable if the other concerns were not as big a concern.
To address the "suddenly all pgrx extensions look the same to tooling" thing, and to allow developers to have more than one pgrx extension in a workspace... more common than you might think... I (currently) think we're best off using the crate name plus a suffix so as to indicate our schema-generator's binary name. Perhaps just giving up on Either way, we also can help ourselves by adding notes to the Cargo.toml using a |
I opened rust-lang/cargo#13312 and got some interesting feedback: using the same bin name for all of these can definitely cause problems. |
d11dbbc
to
d4fbdad
Compare
Just to check, we no longer use |
Yes, we no longer use |
|
Signed-off-by: usamoi <[email protected]>
Signed-off-by: usamoi <[email protected]>
|
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.
re: 5566cea yeah that can get a bit long...
I might take a look later at adjusting the exact way that is handled before 0.12.0 actual... We may want to use the package metadata table to record a name, for future evolution purposes, and use that to make it more concise. It also would let people to rearrange their repo how they want, assigning whatever binary and file names they want, without confusing the pgrx tooling.
That's not a blocking concern for this, however. This looks great and a new extension passes cargo pgrx test all
after doing the path
hack and rerunning cargo pgrx init
, which means that all we need to make this reusable is to publish it. This opens up so many possibilities! Thank you.
@usamoi: Thanks for all your work here. You too, of course, @workingjubilee. It's really special that someone from the community helped solve this problem. Much appreciation and respect! |
I noticed #1468 would allow us to also remove a dependency or two from cargo-pgrx, so I started work by removing once_cell from it and a few other spots in our tree, although we use it so pervasively it's not realistic to remove it entirely. It was actually secretly in our public API, behind a `#[doc(hidden)]`, for some reason. I then noticed a bunch of other easy removals from cargo-pgrx: - serde_derive should not be used directly - flate2, prettyplease, syn, and unescape are not directly used anymore - nix crate maintenance has gotten better, but it is a big dep for 1 bool
Welcome to pgrx 0.12.0-alpha.1! Say the magic words with me! ```shell cargo install cargo-pgrx --locked --version 0.12.0-alpha.1 ``` # Breaking Changes ## No more dlopen! Perhaps the most exciting change this round is @usamoi's contribution in #1468 which means that we no longer perform a `dlopen` in order to generate the schema. The cost, such as it is, is that your pgrx extensions now require a `src/bin/pgrx_embed.rs`, which will be used to generate the schema. This has much less cross-platform issues and will enable supporting things like `cargo binstall` down the line. It may be a bit touchy on first-time setup for transitioning older repos. If necessary, you may have to directly add a `src/bin/pgrx_embed.rs` and add the following code (which should be the only code in the file, though you can add comments if you like?): ```rust ::pgrx::pgrx_embed!(); ``` Your Cargo.toml will also want to update its crate-type key for the library: ```toml [lib] crate-type = ["cdylib", "lib"] ``` ## Library Code - pgrx-pg-sys will now use `ManuallyDropUnion` thanks to @NotGyro in #1547 - VARHDRSZ `const`s are no longer `fn`, thanks to @workingjubilee in #1584 - We no longer have `Interval::is_finite` since #1594 - We translate more `*_tree_walker` functions to the same signature their `*_impl` version in Postgres 16 has: #1596 - Thanks to @eeeebbbbrrrr in #1591 we no longer have the `pg_sql_graph_magic!()` macro, which should help with more things in the future! # What's New We have quite a lot of useful additions to our API: - `SpiClient::prepare_mut` was added thanks to @XeniaLu in #1275 - @usamoi also contributed bindings subscripting code in #1562 - For `#[pg_test]`, you have been able to use `#[should_panic(expected = "string")]` to anticipate a panic that contains that string in that test. For various reasons, `#[pg_test(error = "string")]` is much the same. Now, you can also use `#[pg_test(expected = "string")]`, in the hopes that is easier to stumble across, as of #1570 ## `Result<composite_type!("..."), E>` support - In #1560 @NotGyro contributed support for using `Result<composite_type!("Name"), E>`, as a case that had not been handled before. ## Significantly expanded docs Thanks to @rjuju, @NotGyro, and @workingjubilee, we now have significantly expanded docs for cargo-pgrx and pgrx in general. Some of these are in the API docs on https://docs.rs or the READMEs, but there's also a guide, now! It's not currently published, but is available as an [mdbook](https://github.com/rust-lang/mdBook) in the repo. Some diagnostic information that is also arguably documentation, like comments and the suggestion to `cargo install`, have also been improved, thanks to @workingjubilee in - #1579 - #1573 ## `#[pg_cast]` An experimental macro for a `CREATE CAST` was contributed by @xwkuang5 in #1445! ## Legal Stuff Thanks to @the-kenny in #1490 and @workingjubilee in #1504, it was brought to our attention that some dependencies had unusual legal requirements. So we fixed this with CI! We now check our code included into pgrx-using binaries is MIT/Apache 2.0 licensed, as is common across crates.io, using `cargo deny`!. The build tools will have more flexible legal requirements (partly due to the use of Mozilla Public License code in rustls). # Internal Changes Many internal cleanups were done thanks to - @workingjubilee in too many PRs to count! - @thomcc found a needless condition in #1501 - @nyurik in too many PRs to count! In particular: - we now actually `pfree` our `Array`s we detoasted as-of #1571 - creating a `RawArray` is now low-overhead due to #1587 ## Soundness Fixes We had a number of soundness issues uncovered or have added more tests to catch them. - Bounds-checking debug assertions for array access by @NotGyro in #1514 - Fix unsound `&` and `&mut` in `fcinfo.rs` by @workingjubilee in #1595 ## Less Deps Part of the cleanup by @workingjubilee was reducing the number of deps we compile: * cargo-pgrx: reduce trivial dep usages in #1499 * Update 2 syn in #1557 Hopefully it will reduce compile time and disk usage! ## New Contributors * @the-kenny made their first contribution in #1490 * @xwkuang5 made their first contribution in #1445 * @rjuju made their first contribution in #1516 * @nyurik made their first contribution in #1533 * @NotGyro made their first contribution in #1514 * @XeniaLu made their first contribution in #1275 **Full Changelog**: v0.12.0-alpha.0...v0.12.0-alpha.1
Resolves #1369
Motivation of this PR:
cargo-pgrx
after upgrading compilerbinstall
This PR:
cargo run --bin pgrx_embed_${ext_name}
, instead of usinglibloading
crate (unused symbols are removed by linker, so it compiles)This is a breaking change: users need to write
pgrx::pgrx_embed!();
tosrc/pgrx_embed.rs
and add that[[bin]]
to theCargo.toml
, otherwise schema generation will report an error.