Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This commit updates our pgx version to the `0.2`. This brings us back to using stock pgx, and opens the way for Postgres 14 support. The big change for the `0.2` series, and the cause of the version-bump along with most of the changes seen in this commit, is a change to how install scripts are generated: whereas they were previously generated by `cargo pgx` reading through all the Rust files looking for pgx's markers, it is now generated by the pgx-macros themselves. The macros that generate the Postgres shims–`#[pg_extern]`, `#[derive(PostgresType)`, etc–now also generate functions that describe the meaning of these objects. This info, along with a catalog of well-known types are used to generate the equivalent SQL when the extension is run as a binary. There are more details to this than explained here, but the important change for our purposes is that while SQL generation for functions used to be entirely nominal–the generator would look at the names of the argument types and put that in the SQL–it is now type-based. This leads us to a number of changes: 1. Instead of using `type Foo = pg_sys::Datum` when we want raw access to a Datum of a given type, we now have a `raw` module containing slightly more principled raw types. 2. We need to migrate to the upstream `Internal` type, instead of our existing polymorphic one. In order to maximize type safety, and minimize the amount of churn, we provide a new type `Inner<...>` which serves the same role as our old `Internal<...>` type, and add shims to communicate with the SQL generator. Long-term we should communicate with pgx and look into providing richer internal types, or an aggregate generator that creates the shims on its own. 3. `varlena_type!()` is obsolete! Since SQL generation is type-based it can see through our macros and generate the correct SQL despite the actual types not being visible in the top-level files. 4. As part of this we need to move the actual type-creation into the schema-generating modules, we cannot just have the marker there. Something that this commit does not take advantage of, that we may want to consider in the future, is removing the `toolkit_experimental::` qualifications from arguments and return types of experimental functions. Since type schema-qualification is now based on the type and not the path, it should be possible to do so, and should make the code more readable.
- Loading branch information