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

Implement VariadicAny around pg_sys::FunctionCallInfo #1428

Open
workingjubilee opened this issue Dec 6, 2023 · 3 comments
Open

Implement VariadicAny around pg_sys::FunctionCallInfo #1428

workingjubilee opened this issue Dec 6, 2023 · 3 comments
Labels

Comments

@workingjubilee
Copy link
Member

The current FunctionCallInfo is unnecessarily unsafe when presented as an argument to a function. We could have a safe wrapper around it that only exposes sensical behaviors when it is presented as an argument to a function. This could also simplify everything we currently do... pg_getarg, etc.

@workingjubilee workingjubilee changed the title safe FunctionCallInfo wrapper Consider some kind of FnArgs<'a> or FnCallCx<'a> around pg_sys::FunctionCallInfo? Jan 8, 2024
@workingjubilee
Copy link
Member Author

This is made particularly relevant because pgrx has a neat trick where, if the final argument is FunctionCallInfo, it will basically smuggle that in so that you can inspect pieces of the function call state. It might make the most sense to basically have an iterator of "the pieces of argument unpacking".

@workingjubilee workingjubilee added the enhancement New feature or request label Jan 8, 2024
@workingjubilee workingjubilee changed the title Consider some kind of FnArgs<'a> or FnCallCx<'a> around pg_sys::FunctionCallInfo? Implement FnArgs<'a> or FnCallCx<'a> around pg_sys::FunctionCallInfo Jan 25, 2024
@workingjubilee
Copy link
Member Author

This is no longer a "consideration": I have identified this as actually very important to moving forward, because pg_getarg has to be replaced. But I increasingly think pg_getarg itself should not be directly broken, as direct users of it do exist, and they assume the burden, when they call it, of verifying they are calling it soundly, as it is an unsafe fn. I want a safer interface to replace it that moves more of its safety obligations to its construction time.

@workingjubilee
Copy link
Member Author

Also this would be useful for allowing a VariadicAny: #1505

@workingjubilee workingjubilee changed the title Implement FnArgs<'a> or FnCallCx<'a> around pg_sys::FunctionCallInfo Implement VariadicAny around pg_sys::FunctionCallInfo Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant