v0.0.15
This is pgx
v0.0.15. It contains a number of fixes and new features.
Please make sure to update the cargo-pgx
subcommand to v0.0.15 by running:
$ cargo install cargo-pgx
New Features
-
Returning a
Vec<T> where T: PostgresType
from a#[pg_extern]
function is now supported -
When building
pgx
iself, failing to specify the Postgres version feature (ie, --features "pg12") now results in one compilation error instead of thousands. -
pgx
's schema generator now applies asearch_path
setting to every#[pg_extern]/#[pg_operator]
function it generates. This change now requires that extensions berelocatable = false
. This is set in the extension's.control
file and needs to be updated as the previous default wastrue
. Failure to do so will result in an error duringpgx
's schema generation phase. -
Postgres versions are updated to the latest point releases. If you'd like to also upgrade to those, simply re-run
cargo pgx init
. Your existing databases will be preserved. -
cargo pgx test
now has a--release
flag. -
Invent
cargo pgx connect pgXX
to connect to the specific Postgres instance without compiling/installing an extension. -
New
#[derive(PostgresEq, PostgresOrd, PostgresHash)
traits for automatically generating semantically equivalent Postgres operator functions, along with operator classes/families, allowing such types to be used in Postgresbtree
andhash
indices. -
The
extension_sql!()
macro is validated at compile time. -
Safe support for Postgres' Shared Memory and LWLock system. We currently support custom types (Copy/Clone), types from
heapless
, and standard Rust atomics -- allowing for safe usage of these types across Postgres backends. -
The
_PG_init()
and_PG_fini()
functions now only need#[pg_guard]
applied. It is no longer necessary to apply#[allow(non_snake_case)]
to avoid compiler warnings.
Fixes
-
pgx
's schema generator now processes.rs
files in alphabetical order to
ensure consistency across platforms/filesystems -
Adjust the order in which DDL objects are generated
-
Functions behind
#[pg_guard]
are no longer allowed to be called by threads. Doing so will result in apanic!()
. This ensures, at runtime, that function calls to Postgres only happen on the main thread. This check is disabled in--release
builds to avoid runtime overhead in such builds. -
panic!()
s from threads are logged to stderr (which should go to your Postgres log file), rather than being converted into Postgresereport(ERROR)
s.