Skip to content
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

make #[pg_guard] less internally confusing #1723

Open
workingjubilee opened this issue May 29, 2024 · 1 comment
Open

make #[pg_guard] less internally confusing #1723

workingjubilee opened this issue May 29, 2024 · 1 comment
Labels
docs Improvements or additions to documentation refactor Changes would be considered a refactor of existing functionality.

Comments

@workingjubilee
Copy link
Member

I had a talk with @eeeebbbbrrrr about FFI stuff in the context of #1661.

During that conversation, we made mistakes/were confused on which of the two major functions (pg_guard_ffi_boundary and pgrx_extern_c_guard) are used for which case (decorating an extern "C" fn rust_callable_by_c(Args) -> Ret { expr } and decorating an extern "C" { fn c_callable_by_rust(c_type) -> c_type; } binding declaration) like three times in that conversation. The reason it was only three was that I was talking slowly because I was confused and still only halfway through my second coffee.

We need to make sure which-is-which is eye-bleedingly clear to ourselves. At minimum, via documentation (which could also cover #1406).

@workingjubilee workingjubilee added docs Improvements or additions to documentation refactor Changes would be considered a refactor of existing functionality. labels May 29, 2024
@workingjubilee
Copy link
Member Author

We also discussed splitting the macro into two parts, so it's harder to confuse ourselves, but the internal structure when-to-use-what being clear is more important than the external API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Improvements or additions to documentation refactor Changes would be considered a refactor of existing functionality.
Projects
None yet
Development

No branches or pull requests

1 participant