Add libpq/auth.h

[daamien]

This will expose the ClientAuthentication_hook

[eeeebbbbrrrr]

Looks like this one will require an extra system dependency. Any chances we can make that better?

[daamien]

yes the libkrb5-dev package is required. I missed it because I'm lazy :)

Sorry about that

[workingjubilee]

What exactly is the goal of the authentication hook being included here?

[workingjubilee]

I anticipate our response to this is much the same as #2117: Even if we can get it working in CI, this probably will add too much friction to dev with pgrx. We probably should just handbind everything we want instead, and I think we're happy to host the hand-bindings upstream and keep them consistent on version updates, as long as they are what we need and no more and we document what we are binding them from. This is an unfortunate flaw of bindgen, because it tries too much to be a C compiler, even when it doesn't need to be.

[eeeebbbbrrrr]

I think in general anything that comes from libpq just can't (shouldn't!) be included in pgrx.

Perhaps we could have a separate crate with its own bindgen and such just for libpq bindings. I suspect that would be a lot of work to get going but that's probably the best approach for us.

I'm not volunteering to do that, however.

---

As an aside... I haven't studied any of the libpq headers but maybe there's a different path where for pgrx' purposes we can #undef certain things so as not to require some of these external dependencies?

[workingjubilee]

@eeeebbbbrrrr The structs that most people want are ABI-compatible across "having SSL" or "not having SSL" (or similar configurations... the field remains in-place, it just is a void* instead of ssl* or whatever), so we can just define them by hand in an ABI-compatible way without much issue.

[workingjubilee]

Mind, we could do bindgen + undefining the HAVE_SSL and whatnot, but that feels more fragile and "whack-a-mole" than accepting this as a case we should do hand-binding, which will introduce a handful of moles to whack but we will know exactly which ones. I feel it is preferable because we then get to see exactly what we have bound and to limit our surface of responsibility: I think we would both prefer that pgrx, for instance, stay essentially oblivious to any cryptographic operations that can be done using Postgres APIs. We only want some things that are in libpq because they "open the door" to interact with SSL's types, but we should not support any such interactions.

[daamien]

Many Thanks for taking the time to look into this. I was not aware of this complexity when I submitted the patch. The mere thought of how to install the Kerberos headers on windows is already frighenting me 😨

I am willing to give a try at the hand binding solution if that's the preferred option and if there's a practical example that I could rely. Other than that I don't have enough time to explore any further.

I am ok to close this PR if you think this is too much of a hassle....

[workingjubilee]

For handwriting bindings, you just do what bindgen does automatically: you write out the struct definitions and check they are correct. This allows you to, because you are editing them by hand, replace types that are unimportant with alternative stubbed-out type definitions: when they are behind a pointer, it doesn't matter.