refactor(c/driver/postgresql): Cleanups for result_helper signatures

[WillAyd]

No description provided.

[WillAyd]

Note the change in the paramater declaration from const int& to int

It may not matter, but I believe the const reference type just adds an unnecessary layer of indirection

[lidavidm]

Yeah, AFAIK there is little reason to use const int&

[paleolimbot]

I don't see any problems with this if it works, but we don't aggresively define noexcept in other places and I'm wondering why that is?

[paleolimbot]

Something else to note about the PqResultHelper is that it would really better be served by being a PqQueryHelper and a PqResultHelper...the current version is an attempt to at least get all the internal querying we do in the driver in one place but there are definitely improvements (like this one!) to be had!

[WillAyd]

I don't see any problems with this if it works, but we don't aggresively define noexcept in other places and I'm wondering why that is?

Researching this some more I think there may be too much usage of noexcept in the current PR implementation. Here are guidelines I found from the stdlib:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf

My take on it is that many of these methods are "narrow" (i.e. they have some precondition / state) so probably not worth marking this way.

[lidavidm]

noexcept is tricky to use. I think ReleaseResult is the only thing here that may be marked noexcept, and some of the very trivial getters/setters. Any memory allocation may throw and an assignment may actually be a copy so it often does not apply even if the body seems trivial.

[WillAyd]

OK cool - I'll scale the noexcept back a lot here.

Any memory allocation may throw

FWIW the cpp core guidelines suggest that you may still want to mark functions that can throw because of OOM issues as noexcept:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept

[lidavidm]

Ah, good to know. I suppose that means on the contrary nearly everything here could be noexcept, since we don't use exceptions...but in that case we may as well disable exceptions altogether if we're that sure