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

Unbox types properly from arrays #1476

Conversation

workingjubilee
Copy link
Member

@workingjubilee workingjubilee commented Jan 13, 2024

Introducing Datum<'src> allows using it with HRTB fns in schema generation to persist lifetimes all the way through #[pg_extern]'s wrapper-fn infrastructure without compromising the integrity of lifetime annotations. This is immediately implemented to prevent many types from exceeding the lifetime of the Array they are unboxed from, unless they are already "self-owned" and thus 'static.

Unfortunately, this does not fix all instances using pg_getarg, and those simply are left unsolved for now in some cases. I reorganized the UI tests to make it easier to notice these problems and when they get solved.

@workingjubilee workingjubilee marked this pull request as ready for review January 15, 2024 05:28
@workingjubilee
Copy link
Member Author

workingjubilee commented Jan 15, 2024

I can split this down the line of a0184f4 and e8ead32 if you want, and I can add more notes explaining the lifetimes, names, etc. but this seems like it would benefit from a cursory glance to inform that step, at least.

Copy link
Contributor

@eeeebbbbrrrr eeeebbbbrrrr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jubilee, this looks really clean. It's clear you put a lot of thought into this to basically only have a few lifetime signature changes throughout the code.

Speaking of which, I'm surprised PgHeapTuple didn't require more effort than this. Cool.

}
}

pub fn staticize_lifetimes(value: &mut syn::Type) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goodby, staticize_lifetimes... you will not be missed!

@@ -55,7 +55,7 @@ fn warning(s: &str) -> bool {
#[pg_extern]
fn exec<'a>(
command: &'a str,
args: default!(Vec<Option<&'a str>>, "ARRAY[]::text[]"),
args: default!(Vec<Option<String>>, "ARRAY[]::text[]"),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a question... why this change?

Could it not be Vec<Option<&'a str>>?

This was the only example you touched, so either that means this example is the only one that accepts a &str and that pattern is no longer valid, or you changed this for some other reason?

Copy link
Member Author

@workingjubilee workingjubilee Jan 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this changes FromDatum in the impls in pgrx/src/datum/array.rs to be in terms of T: UnboxDatum with certain bounds, this PR currently breaks FromDatum specifically for Vec<Option<T>> where there is any doubt as to whether T implements UnboxDatum. Essentially, the trait resolver can't figure it out at that depth. This can be solved by involving additional traits which work differently and either allow Vec<Option<T>> to not depend directly on Array<'_, T> for its unboxing or to move pg_getarg (or its replacement) off T: FromDatum.

@workingjubilee
Copy link
Member Author

Speaking of which, I'm surprised PgHeapTuple didn't require more effort than this. Cool.

GitHub won't open it implicitly because it is a "large diff", but unfortunately, pgrx-tests/src/tests/heap_tuple.rs betrays how many cases won't work now, and so this isn't really finished work. I had a PR similar to this a couple months ago, which did (more) damage, but I needed all the work until now to understand whether it would be viable to even fix, and to fix a number of less-complex cases that hinged on that groundwork. I need to add in a bunch more changes to make all of the cases work that need to work properly. Some of those hinge on SPI, which started busted and remains busted.

...Ultimately I am unconcerned about making PgHeapTuple<'a, WA> work really well, because I now believe it's the wrong abstraction in the long run, so as a warning, I have accepted most of those examples getting broken on a semi-permanent basis.

@workingjubilee
Copy link
Member Author

I added the currently-broken tests to the set of ui tests, and reorganized tests slightly, so that it will be easier for us to notice when those problems are fixed.

@workingjubilee workingjubilee changed the title Allow unboxing types properly-ish Unbox types properly from arrays Jan 17, 2024
Lifetimes should be named for their upper bound, and Datum<'dat>
is bound on the source of the Datum.
@workingjubilee workingjubilee merged commit 4fa87bd into pgcentralfoundation:develop Jan 17, 2024
8 checks passed
@workingjubilee workingjubilee deleted the hrtb-fns-and-unboxing-arrays branch January 17, 2024 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants