Expose inline table_* APIs

[nikkhils]

While functions like table_beginscan* are available the corresponding end functions like table_endscan are not. Expose these now. They are not available in PG11 and PG12 already had this header file included.

[nikkhils]

@eeeebbbbrrrr @Hoverbear looks like static inline functions from header files are not available?

I added the tableam.h header file and wanted to use the table_endscan inline function from it. But looks like it's not visible?

[nikkhils]

Hmm, I see that https://rust-lang.github.io/rust-bindgen/faq.html does not support static inline functions for a reason. I can close this PR in that case. Thoughts?

[Hoverbear]

Hi @nikkhils , thanks so much for exploring this. :)

Let's hear what @eeeebbbbrrrr thinks, maybe we need to create an pgx api for this.

[workingjubilee]

It is my understanding that a static function has limited linkage, and an inline function is intended to be inlined, so a static inline function may not have anything to reliably link to from Rust's "outside view" and is mostly for use by the compiler/linker of the source itself, am I wrong?

[nikkhils]

@Hoverbear yeah, converting some static inlines into macros in pgx sounds like a good idea. A macro like table_endscan would definitely make a lot of sense.

macro_rules! table_endscan {
    ($scan:ident) => {{
        let cat_relation_ref = unsafe { (*$scan).rs_rd.as_ref().unwrap() };
        let table_am = unsafe { cat_relation_ref.rd_tableam.as_ref().unwrap() };
        unsafe { table_am.scan_end.unwrap()($scan) };
    }};
}

@workingjubilee it's also a performance thingy. You have static inline functions to avoid the overhead of calling a function.

[eeeebbbbrrrr]

We have a cshim (https://github.com/tcdi/pgx/tree/master/pgx-pg-sys/cshim) whose goal is to wrap Postgres #defines (and other static-inline functions) into plain old functions. And then we have manual extern "C" declarations for those in the pgx-pg-sys create (the cshim isn't run through bindgen -- hmm, maybe it should be!).

So my main thought is that we'd need to wrap all of this stuff, manually. I'm not sure if essentially porting these things to Rust is a good idea. Postgres has the power to just completely rewrite these things from version to version, including in point releases if they want. Seems it'd be quite difficult for us to track that.

[workingjubilee]

This PR appears to be stalled. You are of course welcome to reopen this one or ask for guidance, but for now I am going to close this. Thank you for offering.