Skip to content

Releases: pgcentralfoundation/pgrx

v0.12.0-beta.4

14 Aug 16:08
3f8ee77
Compare
Choose a tag to compare
v0.12.0-beta.4 Pre-release
Pre-release

pgrx 0.12.0-beta.4 will likely be the final beta release and we will be releasing 0.12.0 based on this code with almost no variation if no unpleasant surprises are discovered.

Misc Changes

  • Some doc fixes from @SteveLauC, thank you!
  • A number of FFI headers:
    • add bindings of syslogger.h by @usamoi in #1783
    • Add bindings for 'tcop/pquery.h' and 'commands/copy.h' header files by @aykut-bozkurt in #1786
    • Include pg_seclabel catalog by @daamien in #1787
    • Add bindings for 'jit/jit.h' and 'utils/resowner_private.h' header files by @jeltz in #1790

Postgres 17 beta2 support

Thanks to @eeeebbbbrrrr in #1790 we now have support for Postgres 17's beta2 release. This will be updated to whatever's actually current before we release 0.12.0 properly.

New bindgen settings

For this release, I extensively reworked our CI to make new releases easier and faster, by validating that the build problems that occurred for the pgrx 0.12.0-beta.0 release never happen again. This involved splitting out our bindgen-running code into its own crate, which you will see in your dependency tree, though you should never have a reason to explicitly depend on it. Now we test that the pgrx workspace always can be packaged in CI, and we verify that code on publishing.

As part of this I also did some additional tuning on our bindgen settings in #1804 so that it now generates &CStr for appropriate constants (same content as the &[u8] you may have used before).

New Contributors

Full Changelog: v0.12.0-beta.3...v0.12.0-beta.4

v0.12.0-beta.3

16 Jul 00:46
b875b0b
Compare
Choose a tag to compare
v0.12.0-beta.3 Pre-release
Pre-release

An internal API fixup later, and now you can actually read the docs for pgrx::callconv!

What's Changed

Full Changelog: v0.12.0-beta.2...v0.12.0-beta.3

v0.12.0-beta.2

10 Jul 04:59
215af07
Compare
Choose a tag to compare
v0.12.0-beta.2 Pre-release
Pre-release

Mostly, we filled in a bunch of small gaps that were found in pgrx's type implementations because we lacked adequate testing.

Otherwise, see the release notes for 0.12.0-beta.0!

What's Changed

Full Changelog: v0.12.0-beta.1...v0.12.0-beta.2

v0.12.0-beta.1

07 Jul 04:29
b8392e7
Compare
Choose a tag to compare
v0.12.0-beta.1 Pre-release
Pre-release

Somehow we were missing a build directory and the nuances of our publishing requirements and Cargo prevented us from noticing this. Otherwise, see the release notes for v0.12.0-beta.0! Thanks to @danbluhmhansen in #1756 for catching this!

New Contributors

Full Changelog: v0.12.0-beta.0...v0.12.0-beta.1

v0.12.0-beta.0

05 Jul 21:57
861845f
Compare
Choose a tag to compare
v0.12.0-beta.0 Pre-release
Pre-release

Hello!

NOTE: You should actually upgrade to

In pgrx 0.12.0-beta.0 0.12.0-beta.5, the first news of import is that if you run

cargo install cargo-pgrx --version 0.12.0-beta.5 --locked

You should then be able to run

cargo pgrx upgrade --to 0.12.0-beta.5

in your project to update all of the versions of pgrx libraries in your project's Cargo.tomls. Please let us know how it goes!

Many cargo-pgrx updates and modifications

Internal improvements

  • @usamoi made most of our generated bindings #[inline] in #1616 which will defer codegen until the FFI guard is actually used, which should improve build times considerably
  • Memory management for Datum to String conversion by @sardination in #1684 should reduce allocations
  • Use Ceescape's sigsetjmp() wrapper by @NotGyro in #1621 takes care of a UB concern where sigsetjmp and siglongjmp aren't concepts that can be reflected in Rust code, and thus must be called when Rust "isn't looking": inside asm!. Without this, these calls may be miscompiled, because LLVM may strip the "returns-twice" codegen annotation from them.
  • @JelteF fixed an odd case where OnceLock improperly modeled the lifetime of a Postgres extension, which may persist between resets of the server by using UnsafeCell for PgLwLock and PgAtomic in #1696

New API

Time breakage

Several of our datetime APIs were incorrect in various ways. On the positive side, the remaining functions should no longer panic.

New FFI bindings

We have added many more bindings to the cshim and pgrx-pg-sys!

Breakage of many functions

The pgrx::srf module, which contained no visible code, is no longer accessible.

A number of changes in a hidden module have been done, in conjunction with alterations to the supporting code that #[pg_extern] generates, to make the process of "unboxing" arguments and "boxing" returns... transforming them to and from Datums, specifically at function boundaries... sound. If your code has been broken, it either is a rare and specific SetOfIterator or TableIterator type or it was probably unsound, especially if it used the 'static lifetime. Please report any unexpected breakages.

Fortunately, this has upsides beyond just soundness: now lifetimes in pgrx functions should simply work, and work correctly.

The PRs of interest:

Documentation improvements

If you use mdbook you can generate our documentation. Unfortunately it isn't published yet. We've been making various small improvements to it.

Span adjustments for diagnostics/linting

A number of fixes have been done to how pgrx generates code so that the code should now be detectable as macro-expanded code while still pointing to the appropriate code in errors. There are still diagnostic improvements to be had and this is not done uniformly across all of pgrx yet, so please report if there are issues with these.

Deprecations

A number of things have been deprecated gracefully rather than simply unceremoniously dumped.

New Contributors

Full Changelog: v0.12.0-alpha.1...v0.12.0-beta.0

v0.11.4

19 Apr 12:01
Compare
Choose a tag to compare

Welcome to pgrx v0.11.4!

This is a minor release to add some additional functionality to cargo-pgrx to enable running tests in atypical CI configurations and the ability to turn off its colored output via the NO_COLOR environment variable. This minor release also includes a small change that should measurably improve compilation times for all extensions.

To update to this this, please run cargo install cargo-pgrx --version 0.11.4 --locked and ensure to update your extension's Cargo.toml file to use pgrx v0.11.4.

What Changed

cargo-pgrx changes

PR #1652 was cherry-picked into this release to include the new --runas and --pgdata arguments to cargo pgrx test. --runas uses the system sudo command to run the temporary Postgres cluster process as the specified user, and uses --pgdata as the location where the cluster's PGDATA directory should be initialized.

cargo-pgrx now understands the NO_COLOR and FORCE_COLOR environment variables supported by the upstream dependency it uses for generated colored output. See https://crates.io/crates/owo-colors for details. This is from PR #1664

Compilation Times

pgrx generates a (very large) set of Rust bindings that represent the "rust version" of all the internal Postgres symbols (functions, globals, etc). In the case of functions, pgrx also generates wrapper functions so it can instrument calls with the proper guard rails. It turns out, simply annotating these wrapper functions with #[inline] drastically improves compilation time as it allows the rust compiler to defer their compilation until the very end. Which ultimately means only the functions used by an extension get compiled -- the others are DCE'd. This came from PR #1616.

Thanks!

Thanks to @usamoi for improving our compilation times, and shout out to @theory for his first contribution!

Full Changelog: v0.11.3...v0.11.4

v0.12.0-alpha.1

01 Mar 04:56
db7b09d
Compare
Choose a tag to compare
v0.12.0-alpha.1 Pre-release
Pre-release

Welcome to pgrx 0.12.0-alpha.1!

Say the magic words with me!

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?):

::pgrx::pgrx_embed!();

Your Cargo.toml will also want to update its crate-type key for the library:

[lib]
crate-type = ["cdylib", "lib"]

Library Code

  • pgrx-pg-sys will now use ManuallyDropUnion thanks to @NotGyro in #1547
  • Due to other uses of that name, ErrorReport::report is now unwrap_or_report! #1568
  • VARHDRSZ consts 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 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

#[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

In particular:

  • we now actually pfree our Arrays 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.

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

Full Changelog: v0.12.0-alpha.0...v0.12.0-alpha.1

v0.12.0-alpha.0

25 Jan 20:58
9429f99
Compare
Choose a tag to compare
v0.12.0-alpha.0 Pre-release
Pre-release

Hello and welcome to The Beginning of The End!

You may have seen some largely-inscrutable rambling about "object lifetimes" and "memory contexts" from me in various comments, logs, and issues. You may have also heard that this has effectively stalled all forward feature work. You may have noticed this has been the case for months now.

The long and short of it is that pgrx never actually fully built-in the actual lifetimes of objects in Postgres into its various types. As more and more interlocking parts grew, between things like the type unboxing in trait FromDatum, or the bounded memory context of Spi::connect, eventually many supposedly-safe interfaces arose which proved wildly unsafe in reality due to this mesh of interactions. Internal portions of pgrx relied on expeditious hacks to ignore the growing problems, until this rotten foundation yielded an enormous crop of soundness issues over the year of 2023. Even when not exploitable, they prevent otherwise-trivial enhancements in terms of speed or memory usage.

Key elements of a new foundation have landed in pgrx, which allow ascribing lifetimes to every datum and every memory context that a Postgres extension will encounter. There is much more work to be done to actually make it so all Rust code has to flow through these new interfaces. This alpha release is an extremely "preview" release to allow assessing some of the damage from the first set of breaking changes, so that some initial feedback and triage can occur. There will, unfortunately, be more breaking changes on the horizon.

There are so many small changes that I am simply going to summarize the main point of them:

Many Macros Expand Subtly Differently

If your extension now breaks in some inscrutable way that you cannot otherwise discern, the problem is probably hidden in macro expansion. This cannot really be diagnosed except using cargo expand diffed against previous expansions. A most likely issue is that something that previously hid a lifetime during expansion or writes it as 'static now propagates it by name or as the anonymous '_ lifetime.

Datum<'src>

There are now lifetime-bound Datums. Expect to see them in more places.

UnboxDatum<As<'src> = Type<'src>>

Expect to see this or a similar signature a lot: there are new conversion traits which use a generic associated type or similar sneaky tactics to allow "clamping down" the lifetime to a bound, unless the produced type is always 'static by being a simple value like i32.

&'mcx MemCx<'_>

You will see more and more references to this type, which is a memory context that encodes an inner invariant lifetime, in signatures. If one of these is currently in-scope, then please remember it is always unsafe to manipulate the static mut CurrentMemoryContext in Postgres, but it is doubly so then. In general, when designing your own types using pgrx, you should prefer designing code that uses a signature like that of MemoryContextAlloc instead of palloc if you are at all uncertain.

Full Changelog: v0.11.0...v0.12.0-alpha.0

v0.11.3

25 Jan 20:48
2244e62
Compare
Choose a tag to compare

The pgrx 0.11.3 release addresses several UB risks of pgrx, updates its dependencies to address possible security risks on a few points, and includes considerable numbers of additional headers in the release. It should also now be easier to actually use cargo-pgrx on a mildly more interesting network configuration, though you may need to specify --no-default-features with either --features native-tls or --features rustls when you cargo install cargo-pgrx.

New Bindings!

New bindings added thanks to

"...wait, that's UB?"

Two UB fixes!

Ergonomics

  • A better ereport! macro in #1472

Less transport-level security problems in cargo-pgrx

  • We no longer secretly require rustls thanks to @jirutka in #1448
  • We now use native certs if possible, even with rustls, in #1449

Together these should mean it's possible to actually use cargo-pgrx on whatever your network configuration is, but you might have to use cargo install --no-default-features --features native-tls to install with native-tls (which, on Linux, means OpenSSL). By default, you will use rustls.

Many tiny dependency updates

These address some largely-hypothetical security risks, but one is particularly important: the bindgen update means we now should be compatible with some aarch64 builds that might have failed.

Full Changelog: v0.11.2...v0.11.3

v0.11.2

05 Dec 22:41
14b063e
Compare
Choose a tag to compare

pgrx v0.11.2 is a minor release which

  • makes available the storage-related API, thanks to @silver-ymz in #1409
  • deprecates the Oid::from_u32_unchecked API... because it is actually possible to do via casting in a query, which makes it effectively impossible for us to not wind up providing it via some other safe API, since the source is also an easily-Copied type. Thus you can now simply use From::from for it. Thanks to @thomcc for this discovery, implemented by @workingjubilee in #1374

As usual, cargo install cargo-pgrx --version 0.11.2 --locked and be on your merry way!

Thanks everyone!

Full Changelog: v0.11.1...v0.11.2