-
-
Notifications
You must be signed in to change notification settings - Fork 297
Added pg_binary_protocol
attribute to derive send and receive functions for PostgresType
#2068
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
Added pg_binary_protocol
attribute to derive send and receive functions for PostgresType
#2068
Conversation
pg_binary_protocol
attribute to derive send and receive functions for PostgresType
d323e24
to
2f3d5bf
Compare
@LucaCappelletti94 this is on my radar -- I just don't have time to dedicate to a proper review at the moment. I hope to get to it this week. |
No worries, let me know if there is anything I can do to facilitate the review process |
FWIW, this overall looks ok to me, in terms of what it does. I tested it on one of my projects that has custom types. |
I will likely be doing an extended version afterwards, first trying to tackle the fixed size types as described in my issue #2076 |
Please do let me know whether there is anything I can do to facilitate the review of this PR - I want to build the fixed-size type derive on top of this PR, and I would like to make sure that first this one is considered a-okay |
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 looks great and well thought out and implemented.
Thanks for your patience and most especially thanks for your work.
Welcome to pgrx v0.15.0. This begins a new series for pgrx that includes support for Postgres 18. As of this release, that means Postgres 18beta1. This release does contain a few breaking API changes but they're largely mechanical. Don't worry, the compiler will let you know! As always, please install our CI tool with `cargo install cargo-pgrx --version 0.15.0 --locked` and then run `cargo pgrx upgrade` in all of your extension crates. If you want to start working with Postgres 18beta1, you'll also need to re-init your pgrx environment with `cargo pgrx init`. That will automatically detect all the latest Postgres versions, including 18beta1. At the top here, I'd like to thank @silver-ymz for the 18beta1 support. It was a pleasant surprise to see that work come from the community -- it's no easy task to add a new Postgres version to pgrx! That said, as Postgres 18 is currently beta, you should consider pgrx' support for it as beta too. Please report any problems with 18beta1 (or discrepancies with other versions) as GitHub issues. Also, this release requires rust v1.88.0 or greater. `if-let` chains are now a thing and we're not afraid to use them. # What's Changed ## Postgres 18beta1 Support * Support Postgres 18beta1 by @silver-ymz in #2056 * pg18 support: add header and implement `#define` by @eeeebbbbrrrr in #2094 * improve pg_magic_func by @usamoi in #2088 ## More Headers * Added `catalog/heap.h` binding by @ccleve in #2072 * include `utils/pg_status.h` by @eeeebbbbrrrr in #2091 ## `cargo-pgrx` improvements * Pass `LLVM_*` variables to `--runas` command by @theory in #2083 * `does_db_exist()`: fix `psql` argument order by @eeeebbbbrrrr in #2093 * `cargo pgrx regress` output is no longer fully buffered by @eeeebbbbrrrr in #2095 * Detect `pgrx_embed` name from lib name by @YohDeadfall in #2035 * Fixed error message if no artifact found by @YohDeadfall in #2034 * `cargo-pgrx`: use system certificate store for HTTPS validation by @charmitro in #2074 * Decoding command output in Windows by @if0ne in #2084 ## Breaking Changes * fix GUC by @usamoi in #2064 * refactor GUC by @usamoi in #2066 ## New Stuff * Added `pg_binary_protocol` attribute to derive send and receive functions for `PostgresType` by @LucaCappelletti94 in #2068 * Expose guc hooks by @thesuhas in #2075 * Allows to create multiple aggregates for the same Rust type by @if0ne in #2078 ## General Code Cleanup * `cargo clippy --fix` by @eeeebbbbrrrr in #2092 * Use `if-let` to unpack Options by @stuhood in #2089 * docs: fix typo in `rust_byte_slice_to_bytea()` docs by @burmecia in #2071 * Added a missing `#[doc(hidden)]` by @LucaCappelletti94 in #2079 ## Administrative * Updated Fedora to latest in CI by @YohDeadfall in #2085 * fix ci on beta rust (1.89) by @usamoi in #2087 ## New Contributors Much thanks to our new contributors! Your work is sincerely appreciated! * @charmitro made their first contribution in #2074 * @thesuhas made their first contribution in #2075 * @if0ne made their first contribution in #2084 * @stuhood made their first contribution in #2089 **Full Changelog**: v0.14.3...v0.15.0
This PR generally addresses issues such as #2060, #1446, #1364, and pksunkara/pgx_ulid#27, and supersedes PR #887.
SEND
andRECEIVE
bindings.*_recv
and*_send
functions in rust, based on the existingserde_cbor
-based methodscbor_encode
andcbor_decode
#[pg_binary_protocol]
decorator to be used alongside thePostgresType
deriveThis PR is not API breaking, as even if people have created functions with naming clashes they would still need to add the attribute on the interested structs.
Many thanks to @YohDeadfall and @zommiommy for their help in understanding better pgrx internals and postgres's binary protocol.
The generated Rust & SQL
Given a custom rust type such as:
The resulting generated rust bindings look like:
And the associated generated SQL looks like:
On Diesel traits
I use
diesel
extensively in my projects, and it uses the binary protocol to send data to PostgreSQL. This PR makes it possible to use Postgres's binary protocol withpgrx
type, so I can now implement diesel'sToSql
andFromSql
traits as follows:P.S. Sorry for the very small commits, but I could only figure out how to compile pgrx inside a Docker and therefore to test it in there I had to push every single small test edit.
P.P.S I have also tried to add support for fixed-size types, but there is too much varlena-specific methods at this time and the amount of code it would be needed for that makes it necessarily a separate PR